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Abstract' This paper reports the experiences encountered in 
the multi-vendor integration processes of SSP and SCP at 
ChungHwa Telecom (CHT), Taiwan, ROC and puts forth some 
suggestions for the goal of successful INAP interworking. 
Intelligent Network of CHT Long Distance Management 
(CHT-LDM) consists of nodes fabricated by three of the major 
telecom vendors in the world. The SSP vendors are Alcatel, 
Lucent, and Siemens while the SCP ones are Alcatel and Stratus. 
Alcatel SCPs provide Personal Number (PN) and Virtual Private 
Network (VPN) services, and Stratus SCPs provide Advanced 
Free Phone (A-080) service developed by IN Project of CHT 
Telecom Labs(CHT-TL). 

In the processes of PN, A-080, and VPN service deployment, 
multi-vendor integrations of IN services and their access platform 
in terms of adherence to the commonly recognized international 
standards are regarded as one of the major goals. The first step of 
IN service deployment is to define the specification of Intelligent 
Network Application Protocol (INAP). The specification of 
CHT-LDM INAP is defined based on ETS 300 374-1 131- 

Based on the INAP specification [8], the integration process is 
divided into three phases: conformance, service feature and 
interworking tests. In all the three testing phases, problems are 
found, clarified, and solved after discussions and negotiations 
with the vendors. These problems can be classified into categories 
by their nature: (1) IE encoding and decoding error, (2) 
parameter decoding failure, (3) parameter value error, (4) 
parameter default value error, (5) functionality error, and (6) 
ACN negotiation error. 

I. Introduction 

For the purposes of ubiquitous availability of IN services 
and uniform distribution of IN call traffic, a uniform IN 
service access platform for PSTN network is required. 
However, Intelligent Network of CHT-LDM consists of nodes 
fabricated by three of the major telecom vendors in the world. 
The SSP vendors are Alcatel, Lucent, and Siemens while the 
SCP ones are Alcatel and Stratus. Alcatel SCPs provide PN 
and VPN services, and Stratus SCPs provide A-080 service 



developed by IN Project of CHT-TL. To the end of uniform 
access of IN services, all SSPs should be able to communicate 
with all SCPs using INAP/SS7 protocol stacks[9-12]; that is, 
multi-vendor integrations of SCPs and SSPs has to be done. 
The benefits of such integrations are remarkable in both new 
service deployments and IN network management. 

In the processes of PN, A-080, and VPN service deployment, 
multi-vendor integrations of IN services and their access 
platform in terms of adherence to the commonly recognized 
international standards are regarded as one of the major goals. 
The first step of IN service deployment is to define the 
specification of INAP. The specification of CHT-LDM INAP 
is defined based on ETS 300 374-1 [3]. The definition of 
specification includes (1) selection of INAP operations, (2) 
selection of opfional parameters of each operation, (3) 
specifying the ranges of parameter values for all selected 
parameters, (4) defining the formats of Network Operator 
Specific (NOS) parameters. 

Attribute to the accomplishment of SS7 interworking tests in 
the past years, the tesfing part of IN service deployment can be 
focused on INAP. Based on the INAP specification [2], the 
integration process is divided into three phases: conformance, 
service feature and interworking tests. First of all, the encoding 
and decoding capabilities of INAP/SS7 signaling of each node 
is checked for its conformance to the specification using a 
protocol emulator. Secondly, Functional Entity Actions (FEAs) 
corresponding to INAP operation(s), which appear as service 
features to subscribers, are tested for their functionalities. Then, 
at service level, the interworking tests of SSPs and SCPs are 
conducted by running down a list of test cases item by item for 
all combinations of SSPs and SCPs. 

In all the three testing phases, problems are found, clarified, 
and solved after discussions and negotiations with the vendors. 
These problems can be classified into the following categories 
by their nature: (1) Information Element (IE) encoding and 
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decoding error, (2) parameter decoding failure, (3) parameter 
value error, (4) parameter default value error, (5) functionality 
error, and (6) ACN negotiation error. 

In this paper, the definition of CHT-LDM INAP 
specification for the 3 services mentioned above is first 
described. Next, three phases of protocol tests are described 
one by one. The problems and solufions are presented in the 
following section. For the goal of successful INAP 
interworking, some suggestions on INAP implementation are 
made in the final section. 

II. Definition of cht-ldm inap specification 

The definition of INAP specification, which* is based on 
ETSI ETS 300 374-1 [3] and the related ITU-T standards [1,2], 
includes (A) selection of INAP operafions, (B) selection of 
optional parameters of each operation, (C) specifying the 
ranges of parameter values for all selected parameters, (D) 
defining the formats of NOS parameters. 

A. Selection of INAP operations. 

In the selection of INAP operations, service features that 
are provided by a service have to be considered. There are 
more than ten service features provided by PN, A-080, and 
VPN services collectively. Among them, only five involve 
communications between SCP and SSP, as listed in the 
following: 

(1) Call Prompt (CP) 

(2) Courtesy Response (COR) 

(3) Alternative Destination on Busy (ADOB) 

(4) Alternative Destination on No Reply (ADONR) 

(5) Multiple Calls (MC) 

With the above four service features, the Basic Call 
Processing (BCP) capability required for call setup, and FCI 
for billing, the selected INAP operations are as listed in Table 
I. 



TABLE I 

CHT-LDM INAP OPERATIONS 



No 


Operations 


Abv. 


FE. 


1. 


Connect 


CON 


SSP 


2. 


ConnectTo Resource 


CTR 


SSP 


3. 


DisconnectForwardConnection 


DFC 


SSP 


4. 


EvcntReportBCSM 


ERB 


SCP 


5. 


FurnishCharginglnfonnation 


FCI 


SSP 


6. 


InitialDP 


IDP 


SCP 
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7. 


Play Announcement 


PA 


IP 


8. 


PromptAndCoilectUserlnformation 


PC 


IP 


9. 


ReleaseCall 


RC 


SSP 


10. 


RequestReportBCSM Event 


RRB 


SSP 


IL 


SpeciaiizedResourceReport 


SRR 


SCP 



B. Selection of optional parameters of each operation. 

The selection of optional parameters is done by excluding 
those that are not implemented or required by the services 
from the basis definition of ETS 300 374-1 [1]. For example, in 
the following ASN.I[6] definition of parameters of InitialDP 
operation, parameter cGEncountered is excluded from the 
definition of CHT-LDM INAP[8]. 

InitialDPArg :~ SEQUENCE{ 

servicekey [0] Servicekey OPTIONAL, 

calledPartyNumber 12] CalledPartyN umber OPTIONAL, 
callingPartyNumber [3] CallingPartyNumber OPTIONAL, 

cGEcount e red [7] CGEcount e r e d OPTIONAL, 

iPSSPCapabiiities [8] IPSSPCapabilities OPTIONAL, 
originalCalledPartylD [12] OriginalCalledPartyld OPTIONAL, 
} 

C. Specifying the ranges of parameter values 

For each one of the selected parameters, the range of its 
value has to be decided such that both communicating entities 
would not encounter any unexpected value in the received 
INAP messages. In the beginning of this stage, the submitted 
PICS [4] of each vendor are first reviewed and compared, and 
in the following meetings with all the involved vendors, 
discussions and negotiations are undertaken to lead to the final 
decisions on the ranges of disputed parameters(e.g., some 
parameters of InitialDP operation as listed in the following 
table). 



TABLE II 

FORMATS AND VALUE RAANGES OF PARAMETERS 





ETSI 


Vendor A 


Vendor B 


CHT-LDM 


MllnitialDF^^ 




-. -i.-"'^ ■■ 






serviceKey 


0..2''-l 


except 0 


0..2*'-l 


1..2-^'-l 


iPAvailable 


NOS 


1 BYTE 


1 BYTE 


1 BYTE 


iPSSPCapabiiities 


NOS 


4 BYTE 


1 BYTE 


4 BYTE 


AdditionalCaliing 


Octet String 


OK 


UP TO 18 


UP TO 18 


PartyNumber 






digits 


digits 


eventTypeBCSM 


1..10,12..18 


except 8&16 


2..7,9,10 


2.. 7,9,10 





D. Defining the formats of NOS parameters. 



NOS parameters are those that cannot be defined for all 



scenarios until the time they are used in an implementation. In 
addition to the two NOS parameters shown in the above table, 
chargingCharachateristics is an indispensable NOS parameter 
of FCI operation for billing. The definition of the format of 
each NOS parameter includes both its syntactical and semantic 
usages. 

III. Protocol TESTS 

Before the protocol tests can be described, IN network 
model has to be specified. The model of IN of CHT-LDM 
follows ETS 300 374-1 [3], as shown in Figure 1. 



IP 
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Non-integrated SRF 

Integrated SRF 

IP 



i 



Fig. 1 . IN model of assist with relay SSP 

A. Conformance tests. 

The purpose of conformance tests is to verify that each 
Functional Entity(FE, i.e., SCP or SSP) has the capabilities to 
decode all the parameters in the received INAP messages and 
to correctly encode the messages required for communications 
with its counterpart in providing a service. In this phase, the 
tests can be done by reviewing the PICS [4] provided by the 
vendors to find out the deviations, if any. The Test Suite 
Structure and Test Purposes Specificafion for SSF and SRF [5] 
is consulted but not adopted due to the tremendous efforts it 
requires. The actual tests of encoding and decoding are 
naturally included in service feature tests. 

B. Service feature tests. 

The service feature tests are performed on both SCPs and 
SSPs (including the associated IP). In addition to the testing of 
encoder and decoder of the System Under Test (SUT) as 
mentioned before, value ranges of parameters can also be 
checked in this phase. Nevertheless, the main purpose is 
functionality test of SUT. 

1) Test Architecture: For the testing of an SCP, a protocol 
emulator is used as an SSP; for that of an SSP, the protocol 
emulator is used as an SCP. The architecture are as shown in 
Fig. 2. 
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Fig. 2. (a) SUT: SSP, (b) SUT: SCP 

2) Test Cases: The five service features listed in Section II 
are involved in the test. The INAP message flows 
correspondent to each of service features are illustrated with 
the following figures. 

(1) Call Prompt (CP) 

(2) Courtesy Response (COR) 

(3) Alternative Destination on Busy (ADOB) 

(4) Alternative Destination on No Reply (ADONR) 

(5) Multiple Calls(MC) 

3) Functionalities of Service Features: The functionalities (or 
Functional Entity Actions, FEAs) associated with the service 
features are listed as check items for this test. These items are 
quite different on different FE. On SSP, functionalities show 
themselves in the results of the tests while on SCP, the FEAs 
has to be checked by running monitoring log. The order of 
check sequence of this test is significant to the efficiency of 
test. We believe that the following sequence is a good one to 
clarify and pinpoint the problems in the test: 

(1) Try to pinpoint the source of problem by test result, 
including error messages, 

(2) Verify the INAP messages including parameters, and 
values of parameters, 

(3) Check FEAs in the monitoring log of SUT. 
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Fig. 3. Courtesy Response 
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The expected result of this test case on SSP is that calling 
party A hears the voice of a prearranged announcement and 
then disconnected; on SCP, no error message appears in the 
message flow. 
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Fig. 4.Call Prompt &BCP 

The expected result of this test case on SSP is that calling 
party A (1) hears a voice prompt, (2) key in some digits, and 
then connected to the called party; on SCP, no error message 
appears in the message flow. In addition, a CDR is created in 
response to FCI. 
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Fig. 5 ADOB 

The expected result of this test case on SSP is that calling 
party A is connected to the called party C after failing to 
reach called party B(Off Hook); on SCP, no error message 
appears in the message flow. In addition, a CDR is created in 
response to FCI. 
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Fig, 6 ADONR 



Calling LE 
IN SAC 



SSP/IP 



SCP 



LE 



Called 



IDP 



FCI/RRB(9) 



CON 



Voice 



ERB(9) 



FCI/CON 



Voice 



j^scpnnec t 



Fig.7 Multiple Calls 

The expected result of ADONR test case on SSP is that 
calling party A is connected to the called party C after 
waiting for the reply of called party B (e.g., 20 sec); on SCP, 
no error message appears in the message flow. In addition, a 
CDR is created in response to FCI. 

The expected result of Multiple Calls test case on SSP is 
that calling party A is connected to the called party B for a 
duration of conversation and then connected to called party C 
after the conversation ends; on SCP, no error message 
appears in the message flow. In addition, a CDR is created in 
response to FCI. 

C Intenvorking tests 



The expected result of ADONR test case on SSP is that 
calling party A is connected to the called party C after 
waiting for the reply of called party B (e.g., 20 sec); on SCP, 
no error message appears in the message flow. In addition, a 
CDR is created in response to FCI. 



Following the completion of service feature tests, 
inter working tests are to be conducted in IN network. Before 
the tests can be done, some network configurations have to be 
arranged. 

1) Test Architecture: As shown in Fig. 8, all the five nodes in 
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the network need to be configured (e.g., ODD for triggering of 
the tested IN service needs to be established on SSPs). 
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Fig.8 Architecture of interworking tests 

2) Test Cases: When the Service Logic Program (SLP) of an 
SCP is ready for test, interworking test can be done by running 
down the test items arranged in the test plan; otherwise, SCP's 
place can be taken by the protocol emulator used in the last 
phase and the test cases are reused again. 



In the phase of interworking tests, the focus is on the 
network-wide and service-wide events, instead of single 
service feature or node. However, the source(s) of problem(s) 
in the test spans all service features and all nodes, which 
explains the necessity of service feature tests. Only when 
service feature tests had been successfully completed, the 
focus of following interwroking tests could be put on 
network-wide and service-wide events, such as Call Detail 
Record (CDR). 

IV. Problems and discussions 

In all the three testing phases, problems are found, clarified, 
and solved after discussions and negotiations with the vendors. 
They are listed in the following tables., in which X-Y 
interworking denotes the interworking between SSP (by 
Vendor X) and SCP (by Vendor Y). 



TABLE UI 
A-B interworking 



Problems 


INAP/TCAP 


Sender 


Receiver 


Remarks 


1. ACN 


Dialogue Portion of 
TCAP 


SSP 


SCP 


ACN refused by SCP** 


2. forwardCalilndicator 


IDP 


SSP 


SCP 


decoding error^ 


3. legID 


RRB 


SSP 


SCP 


incorrect value^ 


4. iPSSPCapability,iPAvaiIab!e 


IDP 


SSP 


SCP 


nos parameter not implemented^ 


5. cancelDigit, endOfReplyDigit 


PC 


SCP 


SSP 


incorrect values'' 


6. variableParts 


PA 


SCP 


SSP 


functionality not ready^ 


7. maximumNumberOfDigit 


PC 


SCP 


SSP 


value out of upper bound^ 


8. TC_CONTINUE with empty component 


TCAP 


SCP 


SSP 


I 

programmmg error 



TABLE IV 
A-D interworking 



Problems 


INAP/TCAP 


Sender 


Receiver 


Remarks 


9. Three parameters of A ARE (indefinite 
form) 


Dialogue Portion of 
TCAP 


SCP 


SSP 


decoding error' 


1 0. Message length (indefinite form) 


TCAP 


SCP 


SSP 


decoding error' 


1 1 . iPSSPCapability and iPAvailable 


IDP 


SSP 


SCP 


NOS parameter not implemented^ 


12. cancelDigit, endOfpIyDigit 


PC 


SSP 


SCP 


3 

misintepretation of values 


13. variableParts 


PA 


SCP 


SSP 


functionality not ready^ 


14. Link ID of TCAP Invoke Component 


PA 


SCP 


SSP 


encoding error (link ID of SRR)' 



TABLE V 
B-D interworking 



Problems 


INAP/TCAP 


Sender 


Receiver 


Remarks 


1 5. VoiceBack & voicelnfomation 


PC 


SCP 


SSP 


decoding error^ 


1 6. iPSSPCapability and iPAvailable 


IDP 


SSP 


SCP 


NOS parameter not implemented^ 


17. additionalCallingPartyNumber 


IDP 


SSP 


SCP 


decoding error 


18. NOS parameter of FCI 


FCI 


SCP 


SSP 


misinterpretation of values^ 
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A. Problems 

These problems can be classified into categories by their 
nature: (1) IE encoding and decoding error, (2) parameter 
decoding failure, (3) parameter value error, (4) parameter 
default value error, (5) functionality error, and (6) ACN 
negotiation error. In the above three tables, the category of a 
problem is denoted by the superscript in the remark of the row. 
For the goal of successful INAP interworking, some 
suggestions on INAP implementation are made, after the 
discussions on these problems. 

B. Discussions 

1) IE encoding and decoding error. The format of An IE is 
a triplet (T, L, V). The type of an IE can be either a primitive 
or a constructor). The length encoding of an IE of constructor 
type can be in either definite or indefinite form, as specified in 
BER [7]. The problems encountered are that the receiver had 
trouble decoding the length of a constructor IE in TCAP 
message. Trouble-shooting procedure consists of the sequence 
of three steps mentioned earlier: 

(1) Try to pinpoint the source of problem by the only 
error messages "TCAP P-Abort," 

(2) Verify the TCAP messages including parameters, 
and values of parameters, 

(3) Check FEAs in the monitoring log of SUT. 

In step (2), after making a scrutiny into the TCAP message 
again and again, we came up with a doubt on the part of 
indefinite length encoding of constructor lEs. A protocol 
emulator was then used to prove the doubt by sending the 
same message of all definite length encoding to the SUT. The 
doubt was proved; the problem was clarified and passed to the 
vendor. The other problems classified in this category are 
explained in the remarks. 

2) Parameter decoding failure. The problems of this 
category are that an SUT failed to decode (or recognize) some 
optional parameters of INAP messages and caused the abortion 
of communication transaction. 

3) Parameter value error. The problems of this category are 
that an SUT is unable to perform the corresponding FEA due 
to the unexpected value(s) of parameter(s) in the received 
INAP message and has the transaction aborted. 

4) Parameter default value error. Same as mandatory 
parameters, parameters with a default value are not explicitly 
specified by the word "OPTIONAL" in the INAP definition of 



ASN.l syntax [6] and may be misinterpreted as the former. 
They are explicitly specified by the keyword "DEFAULT" 
followed by a value which is to be assumed by the receiver 
when they do not appear in the carrying INAP messages. On 
the other side, a sender has the choice of sending or not 
sending a parameter with a default value when the value of 
that parameter coincides with the default value. Otherwise, 
when it has a value different from the default one, the sender 
has to send the parameter. The problems of this category are 
that an SUT assumed incorrect default value(s) for the 
parameter(s) listed above and performed unexpected 
functionalities. 

5) Functionality error The problems of this category are that 
an SUT failed to perform expected functionalities due to 
implementation errors or late implementation. 

6) ACN negotiation error. ACN is carried in the optional 
dialogue portion of TCAP message which contains InitialDP 
message in the component portion sent by an SSP to initiate a 
communication transaction with SCP. It is literally the version 
name of INAP which SSP proposes to SCP as communication 
protocol. This problem was encountered when SCP-B refused 
the ACN proposed by SSP-A. The problem was solved after 
discussions and negotiations with the vendors, and we have 
our ACN uniquely defined. 

V. Suggestions 

Based on the experiences in the trouble-shooting of 
problems encountered in this run of integrations, some 
suggestions on the implementations of INAP (or even all 
protocols) are proposed for the goal of successful system 
interworking. 

1 ) Encoding and Decoding of IE. Both the encoding of all 
IE on a sender and the decoding on a receiver follow the 
specification of BER[7]. 

2) Decoding of Optional Parameters. The decoding 
procedure of a receiver be able to decode all the optional 
parameters defined in the specification of ETS 300 374-1 [3] 
and all the related standards. 

3) Decoding of Private Parameters. The decoding 
procedure of a receiver ignore or discard all the private 
parameters (class 3) and go on the following processing (FEA) 
as long as the encoding follows BER [7]. 

4) Decoding of Private Parameters. The decoding 
procedure of a receiver ignore or discard all the undefined 
context-specific parameters (class2) and go on the following 
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processing (FEA) as long as the encoding follows BER [7]. 

5) ACN negotiation. Both SSP and SCP be able to 
deactivate ACN negotiation procedure by system 
configuration. 

LIST OF ACRONYMS 



ACN 


Application Context Name 


BER 


Binary Encoding Rule 


FE 


Functional Entity 


FEA 


Functional Entity Action 


IN 


Intelligent Network 


INAP 


Intelligent Network Application Protocol 


NOS 


Network Operator Specific 


PN 


Personal Number 


SCP 


Service Control Point 


SLP 


Service Logic Program 


SS7 


Signaling System No. 7 


SSP 


Service Switching Point 


STP 


Signal Transfer Point 


VPN 


Virtual Private Number 
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4. The Lucent Technologies Online Communications Center 

4.1. Overview 



The Lucent Technologies Online Communications Center (OCC) is an 
Intelligent Network (IN) -based platform that supports the Internet 
call waiting service. Its basic components are the OCC Server and 
OCC Client, which are described in detail in the Architecture 
section. The OCC Server interacts with the PSTN entities over the 
secure intranet via plain-text Session Initiation Protocol (SIP) 
messages [2] . With the PC Client, the OCC Server interacts via 
encrypted SIP messages. 

The OCC Server run-time environment effectively consists of two 
multi-threaded processes responsible for Call Registration and Call 
Notification services, respectively. 

OCC call registration services are initiated from an end-user's PC 
(or Internet appliance) . With those, a subscriber registers his or 
her end-points and activates the notification services. (The 
registration services are not, strictly speaking, SPIRITS services 
but rather have a flavor of PINT services.) 

All OCC call notification services are PSTN-initiated. One common 
feature of these services is that of informing the user of the 
incoming telephone call via the Internet, without having any effect 
on the line already used by the modem. (A typical call waiting tone 
would interrupt the Internet connection, and it is a standard 
practice to disable the "old" PSTN call waiting service for the 
duration of the call in support of the Internet connection between 
the end-user and the ISP.) 

When a call comes in, the user is presented with a pop-up dialog box, 
which displays the caller's number (if available), name (again, if 
available), as well as the time of the call. If the called party 
does not initiate an action within a specified period of time the 
call is rejected. 

As far as the disposition of the call is concerned, OCC supports all 
the features described in Section 2. 



4.2. Architecture 



+ 



I Compact I 
I Service I 
I Node (CSN) I 



I Service | 
I Management | 



+ 
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Figure 8: The Lucent OCC Physical Architecture 

Figure 8 depicts the joint PSTN/Internet physical architecture 
3-elevant to the OCC operation. The Compact Service Node (CSN) and 
SCP are Lucent * s implementations of the ITU-T IN Recommendations (in 
particular, the Recommendation Q.1205 where these entities are 
defined) augmented by the requirements of Bellcore's Advanced 

Intelligent Network (AIN) Release 1.0) and equipped with other 
features. The Central Office (CO) may be any switch supporting the 
Integrated Services Digital Network (ISDN) Primary Rate Interface 
(PRI) and the call forwarding feature that would allow it to 
interwork with the CSN. Alternatively, in order to interwork with 
the SCP, it needs to be an IN Service Switching Point (SSP) . In the 
latter case, the central office is connected to the SCP via the 
signaling system No. 1 {SSI) and INAP at the application layer. 

The Service Management System (SMS) is responsible for provisioning 
of the SCPs, CSNs, and central offices. In particular, for IN 
support of the Internet Call Waiting, it must provision the Central 
Office to direct a terminating attempt query to the subsystem number 
corresponding to the OCC SCP SPA based on the Termination Attempt 
Trigger (TAT) . In addition, the Subscriber Directory Number (DN) , 
Personal Identification Number (PIN) and Language ID are provisioned 
for each subscriber into the OCC Subscriber entry of the SCP Real 
Time Data Base (RTDB) . Figure 9 shows the structure of an RTDB 
entry. 

+ + 

IDN I PIN I IP Address | Session Key | CNF | Language ID| 
+ + 

Field Descriptions: 

(DN) Directory Number - the subscriber's telephone number 

(PIN) Personal Identification Number - the subscriber's password 

IP Address - Internet Protocol Address of the subscriber 
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(CNF) Call Notification In Progress Flag (boolean) - the flag 
indicating if an attempt to notify the subscriber of a call is 
currently in progress 

Session Key - unique identifier for the current registration session 
of the subscriber 

Language ID - language identifier for the subscriber 

Figure 9: Structure of the RTDB Subscriber Record 

The Central Office, SMS, CSN, and SCP are the only PSTN elements of 
the architecture. The other elements are VoIP Gateway and Gatekeeper 
defined in the ITU-T Recommendation H.323, whose roles are to 
establish and provide the part of the voice path over IP. The 
Central Office is explicitly connected to the VoIP Gateway via the 

ISDN PRI connection. In this architecture, CSN, VoIP Gateway, and 
VoIP Gatekeeper are the only entities connected to the Internet, with 
each respective connection protected by a firewall. The CSN and SCP 
are interconnected via a secure IP Intranet. There may be more than 
one CSN or SCP (or both) (and the SCPs come in mated pairs 
interconnected by X.25, anyway) in a network, but these details are 
not essential to the level of description chosen for this document. 
However, we note that load balancing and adaptation to failures by 
the use of alternative nodes is incorporated into the architecture. 

When someone attempts to call the subscriber, the central office 
serving that subscriber interrupts normal termination processing and 
notifies the SCP which, in turn, can check whether that subscriber 
has registered that he (or she) is logged onto the Internet. 
Exploiting the standardized layering of service logic that 
characterizes the intelligent network, the central office will do 
this without requiring the installation or development of any central 
office software specific to OCC . The central office is simply 
provisioned to query the SCP when there is a termination attempt 
(i.e., TAT) directed to the subscriber's directory number. (Note 
that the Central Office has no bearer circuit connection to the SCP, 
only a signaling one over SS7) . 

TCP/IP communication between the SCP and CSN utilizes a secure 
intranet. The subscriber, of course, is assumed to have access only 
to the Internet. 

The intelligent network entities, the SCP and CSN, do have OCC 
related software. The OCC server is implemented on the CSN. In 
addition, one service package application (SPA) is installed on the 
SCP. Another SPA is located in the CSN and is needed only when the 
subscriber elects to accept an incoming call using voice over IP. 

The OCC Server is a collection of Java servers on the CSN whose 
responsibilities include : 

o Listening for incoming Call Notification (TCP/IP) messages from 
the SCP SPA. 

o De-multiplexing/multiplexing incoming Call Notification messages 
sent from the SCP SPA. 

o Relaying messages between the OCC Client and the SCP SPA. 
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o Listening for and authentication of OCC Client requests for 
service registration. 

o Handling encryption/decryption of messages exchanged with the OCC 
Client, and generating session-specific encryption/decryption 
keys . 

The OCC Client is a collection of software components that run on the 
Subscriber's PC. Its components include the SIP User Agent Server 
(which handles the exchange of SIP messages with the OCC Server and 
invokes the Call Notification pop-up window) and a daemon process 
that monitors the Point-to-Point Protocol (PPP) actions and is 
responsible for starting and stopping the. SIP User Agent Server. 

4.3. Protocol and Operations Considerations 

The OCC Server uses distinct TCP/IP ports configured on the CSN to 

o Listen for incoming SIP REGISTER messages (in support of 
registration service) sent from the OCC Client. 

o Listen for incoming SIP INVITE messages (in support of call 
notification service) sent from the SCP. 

During call notification, the SCP SPA is the client and thus is 
started after the OCC Server has been started. The SCP SPA and OCC 
Server exchange SIP messages over TCP/IP (via the Secure Intranet) 
using a "nailed-up" connection which is initiated by the SCP SPA. 
This connection is initiated at the time the SCP SPA receives the 
very first SIP REGISTER request from the OCC Server, and must prevail 
for as long as the SPA is in the in-service state. The SCP SPA also 
supports restarting the connection after any failure condition. 

The OCC Server supports multithreading. For each Call 
Notification/Call Disposition event, a separate thread is used to 
handle the call. This model supports multi-threading on a "per 
message" basis where every start message (SIP INVITE) received from 
the SCP SPA uses a separate thread of control to handle the call. 
Subsequent messages containing the same session Call-ID (which 
includes the SPA's instance known as "call_index" and the SCP 
hostname) as the original start message is routed to the same thread 
that previously handled the respective initiating message. 

The OCC Server dynamically opens a new TCP/IP socket with the OCC 
Client for each Call Notification/Call Disposition session. This 
socket connection uses the IP address and a pre-conf igured port on 
the PC running the OCC Client software. 

For session registration, the OCC Server dynamically opens TCP/IP 
sessions with the SCP SPA. The SCP SPA listens at a pre-conf igured 
port to incoming SIP REGISTER messages sent by OCC Clients via the 

OCC Server. To exchange SIP messages with the OCC Server, the OCC 
Client dynamically opens a TCP/IP socket connection with the OCC 
Server using a pre-conf igured port number on the CSN and the CSN ' s IP 
address . 

For the VoIP Scenario, the CSN SPA, acting as a client, dynamically 
opens TCP/IP sessions with the SCP that handled the initial TAT 
query. As soon as the CSN SPA has successfully made the correlation 
and connected the two incoming call legs pertaining to a VoIP call 
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back, the SIP 180 RINGING message will be sent back to the SCP SPA 
running on the actual SCP that instructed the SSP to forward the 
Caller to the CSN. This SIP message, which contains the VoIP Call 
Back DN dialed by one of the bridged call legs, is an indication to 
the SCP SPA that the VoIP Call Back DN is freed up. 

A typical subscription scenario works like as follows: 

1. Each VoIP Gateway is provisioned with a list of authorized VoIP 
Call Back DNs, each terminating on a particular CSN. These 
special DNs are used when an on-line subscriber elects to receive 
an incoming call via VoIP. In particular, they assist in routing 
an outgoing call from the subscriber's NetMeeting to the 
particular CSN to which the SCP is (roughly concurrently) 
forwarding the incoming call. (These two calls are joined in the 
CSN to connect the incoming call to the subscriber's Netmeeting 
client.) Furthermore, these special DNs permits that CSN to 
associate, and hence bridge, the correct pair of call legs to join 
the party calling the subscriber to the call from the subscriber's 
NetMeeting client. 

2. The subscriber calls a PSTN service provider and signs up for the 
service. ^ 

3. An active Terminating Attempt Trigger (TAT) is assigned to the 
subscriber's DN at the subscriber's central office. 

4. The PSTN service provider uses the SMS to create a record for the 
subscriber and provision the Subscriber DN and PIN in the OCC RTDB 
table in the SCP. 

5. The subscriber is provided with the OCC Client software, a PIN and 
a file containing the OCC Server IP Addresses. 

Finally, we describe the particular scenario of the OCC Call 
Disposition that involves voice over IP, which proceeds as follows: 

1. The OCC subscriber clicks on "Accept VoIP". 

2. The OCC Client sends a "SIP 380 Alternative Service" message to 
the OCC Server. This message includes a reference to the Call 
Back DN which will ultimately be used by the CSN to associate the 
call leg (soon to be initiated by the subscriber's NetMeeting) 
connecting to the subscriber (via the VoIP gateway) with the PSTN 
call leg connecting to the calling party. 

3. The OCC Server closes the TCP/IP session with the OCC Client and 
sends to the SCP SPA the "SIP 380 Alternative Service" message 
which includes the Call Back DN . 

4. The SCP SPA instructs the Central Office to forward the call 
incoming to the subscriber to the CSN. This instruction includes 
the Call Back DN. 

5. The SSP forwards the Caller to the CSN referencing the Call Back 
DN. Note that the Call Back DN, originally assigned to the OCC 
client by the SCP when the subscriber was alerted to the presence 
of an incoming call attempt, flowed next to the OCC server when 
the client elected to receive the call via VoIP, then to the SCP, 
then to the central office in association with a SCP command to 
forward the incoming call to the CSN, then to the OCC server on 
the CSN in association with that forwarded call. 
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6. Meanwhile, the OCC Client extracts 1) the VoIP Call Back DN from 
the SIP INVITE message received during Call Notification and 2) 
the H323UID and H323PIN values from its properties file and 
updates the 'netmtg.cnf* file. 

7. The NetMeeting application is launched and sets up a connection 
with the VoIP Gateway. 

8. Once a connection is established between NetMeeting and the VoIP 
Gateway, NetMeeting initiates a phone call - passing to the VoIP 
Gateway the Call Back DN as the destination DN. 

9. The VoIP Gateway consults the VoIP Gatekeeper and authenticates 
the NetMeeting call by verifying the H323UID and H323PIN values, 
and by ensuring the called DN (i.e.. Call Back DN) is authorized 
for use. 

10. After passing the authentication step, the VoIP Gateway dials 
(via PSTN) the Call Back DN and gets connected to the CSN. The 
CSN notes that it was reached by the particular Call Back DN. 

11. The CSN bridges the Calling and Called parties together by 
matching on the basis of the Call Back DN. 

12. The CSN notifies the SCP (SIP 180 Ringing) of status and 
references the Call Back DN so that the SCP can reuse it for 
other calls. 

13. If the central office supports that two B-channel transfer 
(Lucent, Nortel, and perhaps other central office vender's do), 
an optimization is possible. The CSN can have the central office 
rearrange the topology of the newly connected call in such a way 
that it flows only through the central office and no longer 
through the CSN. 
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Lucent Technologies introduces personal 
assistant technology for the broad 
consumer and business markets 

FOR RELEASE WEDNESDAY JANUARY 27, 1999 



WASHINGTON, D. C. - Lucent Technologies (NYSE: LU) 
today introduced the first nnass market personal 
productivity software tool which uses spoken commands to 
control and screen incoming phone calls, simplify 
outbound calls and manage voice mail. The Lucent 
Personal Assistant delivers easier to use, lower-cost virtual 
assistant technology than was previously available, and is 
designed for both consumer and business markets. 
Personal Assistant is available for telephone and mobile 
service providers, who install the software in their 
networks and then offer service subscriptions to their 
customers. The announcement was made here today at 
ComNet '99, an annual exhibition for the networking and 
telecommunications industries. 

' Personal Assistant combines Lucent's cost-effective 
Intelligent Network platform and unique Bell Labs speech 
processing technology to create a simplified, lower-cost 
service than previous personal/virtual assistant offerings. 
Unlike complex assistant services that bill by the minute 
and appeal only to limited niche markets, Lucent's intuitive 
Personal Assistant is designed to be offered for a low 
monthly subscription to the sizable home and business 
telephone markets, as well as the growing legion of mobile 
users. 
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Lucent created a user-friendly personal assistant service 
by avoiding needless complexity, concentrating instead on 
the basic functions of an assistant: 

Screen calls-Personal Assistant answers incoming calls, 
identifies who is calling, then lets users respond by voice 
to answer a given call or to instruct the assistant to send 
the call to voice mail. Place calls-Personal Assistant allows 
subscribers to dial calls by simply speaking a name or 
phone number. 

Take messages-Personal Assistant streamlines voice mail 
playback by grouping messages by caller's names (e.g., 
"You have two messages from John Smith and one 
message from Mary Jones"), then allowing the subscriber 
to quickly select by voice which messages he or she wants 
to hear (e.g., "Play the message from Mary Jones"). 

Find the subscriber as needed-Personal Assistant uses 
call forwarding or sequential ringing (ringing phones in 
different locations in a particular order) to locate 
subscribers and notify them of an incoming call, even if 
they are already on a different call. 

"Personal Assistant leverages critical technologies 
developed across several Lucent businesses, including 
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Intelligent Networking software, speech recognition from 
Bell Labs and voice messaging from the Octel unit," said 
Lance Boxer, group president, communications software, 
Lucent Technologies. "The combined technologies are 
specifically designed with broad home and office usability 
and affordability, which is also attractive for 
communications providers seeking new, revenue- 
enhancing service offerings for their subscribers." 

Personal Assistant also addresses the call management 
needs of business users, who struggle to keep up with the 
crush of calls and voice mail. Additionally, Personal 
Assistant's simplicity is intended to appeal to the average 
home user, who has become more protective of personal 
privacy and is seeking to control interruptions to personal 
time. Personal Assistant is also a vast improvement for 
mobile users, who often find themselves working from 
their cars, where constantly entering keypad commands 
can be difficult. Personal Assistant's spoken, hands-free 
interface is a more-efficient method for mobile 
communications. 

To further promote the mass market acceptance of the 
virtual assistant concept, Lucent will make selected 
features of Personal Assistant, such as Voice Dialing and 
Call Screening, available as stand-alone. Intelligent 
Network-based services. This building block approach 
allows service providers to offer targeted services that 
reflect the specific needs of a variety of markets. The end 
result is a unique suite of assistant services that build on 
users' existing experience, allowing subscribers to easily 
migrate to the complete Personal Assistant service over 
time. 

Deployed on Lucent's standards-based Intelligent Network 
Service Node or Compact Service Node, Personal Assistant 
will operate on a variety of fixed and mobile 
communications networks throughout the world. Lucent's 
proven Intelligent Network platforms provide the reliability 
and scalebility needed to deploy revenue generating 
services such as Personal Assistant to expanding markets. 
Personal Assistant also leverages international language 
expertise from Bell Labs and Lucent Speech Solutions, 
allowing Lucent to offer future versions of the service 
optimized for common languages in North America, South 
America and Europe. 

A market trial version of Personal Assistant is currently 
available on a limited basis to North American service 
providers. 

ABOUT LUCENT TECHNOLOGIES 

Lucent Technologies, headquartered in Murray Hill, N.J., 
designs, builds and delivers a wide range of public and 
private networks, communications systems and software, 
data networking systems, business telephone systems and 
microelectronic components. Bell Labs is the research and 
development arm for the company. More information 
about Lucent Technologies is available on the company's 
Web site at: http : //www.lucent.com . 



For more information, reporters may contact: 

Rich Teplitsky 
Lucent Technologies 

http://www.lucent.com/press/0199/990127.nsc.html 5/31/05 
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908-582-5700 (office) 
1-800-759-8888, #1080016 (pager) 
ComNet '99 DC Booth #856 
Email : rteplitsky@lucentcom 

Dan Coulter 
Lucent Technologies 
908-582-3400 

Email: med larelatlons@ l ucent.com 



View the In formation and polici es regarding Lucent's press 
release archive. 
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Ameritech uses Lucent Technologies 
hardware and software for privacy 
protection services 

FOR RELEASE WEDNESDAY SEPTEMBER 23, 1998 



MURRAY HILL, NJ. - Lucent Technologies (NYSE: LU) 
today announced that it is providing the network hardware 
and software for Anrieritech's new Privacy Manager with 
Sales Screener service, which give custonners more control 
over inconning calls. 

Ameritech's Privacy Manager with Sales Screener- 
introduced yesterday in Chicago and Detroit-is a 
breakthrough service that enables residential customers to 
easily and quickly reject unwanted telemarketing and 
other unwanted calls. 

Privacy Manager will be the first service Ameritech will 
offer through Lucent's new intelligent network platform, 
called Compact Service Node/Intelligent Peripheral 
(CSN/IP). The platform enables Ameritech and other 
service providers to create and offer a variety of new 
services to their customers. The three-year, multimillion 
dollar agreement between the two companies makes 
Ameritech the first customer for the new platform 
designed by Lucent's Bell Labs. 

"Lucent's hardware and software enables Ameritech to 
quickly and efficiently offer these new privacy features," 
said Dave Geary, regional vice president for Lucent 
Technologies. "Consumers want these options, and we 
worked with Ameritech to meet the need." 



Lucent introduced the CSN/IP platform in March and 
Ameritech tested it for three months. In addition to the 
Privacy Manager features, Lucent's CSN/IP enables service 
providers to offer its customers other advanced features 
such as voice-activated dialing, message delivery service 
and intelligent personal agent. 

Message delivery service calls the customer to deliver 
basic information about calls that have come in. Intelligent 
personal agent follows a customer's spoken instructions to 
forward calls to another number, take a message or place 
a call. 

Business customers can use the CSN/IP platform to access 
and update a set of announcements tailored to meet their 
individual needs automatically and without expensive 
manual procedures. 



The CSN/IP supports a complete complement of voice, 
data, messaging and multimedia features so that service 
providers can quickly combine and integrate a wireless, 
wireline or Internet service provider's network and deliver 
services such as speech recognition, text-to-speech, fax 
services and recorded announcements. 
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The platform's support of Internet protocols enables it to 
bridge voice and data networks. Infornnatlon from the 
Internet can be retrieved and delivered to anyone on the 
telephone. Conversely, voice calls and data from the 
switched network can be delivered to emerging data 
networks. 

Lucent's CSN/IP platform-installed in the service provider's 
central offices and administrative centers-consists of: 

• Compact Service Node (CSN) - recognizes and 
responds to customer requests for services. 
Lucent's CSN supports nearly all brands of wireline 
and wireless call-routing switches in service 
providers' networks. 

• Intelligent Peripheral (IP) Manager - collects and 
stores digitized information about services 
available to each customer; 

• Service Control Point (SCP) - works in conjunction 
with the CSN to collect information about calls and 
tell the IP Manager how to handle each call. 

Ameritech (NYSE:AIT) serves millions of customers in 50 
states and 40 countries, Ameritech provides a full range of 
communications services, including local and long distance 
telephone, cellular, paging, security, cable TV, Internet 
and more. One of the world's 100 largest companies, 
Ameritech ( www.ameritech.com ) has 72,000 employees, 1 
million shareowners and more than $29 billion in assets. 

Lucent Technologies, headquartered in Murray Hill, N.J., 
designs, builds and delivers a wide range of public and 
private networks, communications systems and software, 
business telephone systems and microelectronic 
components. Bell Labs is the research and development 
arm for the company. For more information about Lucent 
Technologies, visit the company's web site at 
htt p://www.lucent.com . 



For more information, reporters may contact: 

Gordon Zwirkoski 
Lucent Technologies 
908-582-3400 

Email: mediarelations@lucent.com 



View the information and policies regarding Lucent's press 
release archive. 
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Flexent® High Density 4.0 
Flexent® One Base Transceiver Station (BTS) 
5ESS® 2000 Switch Mobile Switching Centre (MSC) 
Executive Cellular Processor (ECP) 
IMS Ring 

Direct Link Node (DLN), Home/Visitor Location Register 
(H/VLR), Call processing Data Nodes (CDN), Recent Change 
Systenn (RCS) 

Packet Data Network 

O 3G-1X and EVDO 

O Lucent Packet Control Data Function 

O Lucent Packet Inter Working Function (IWF) 

f) 3Com Packet Data Serving Node (PDSN) 
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Radio Network 

O Flexent® Modular Cell 4.0 

O Flexent® Modular Ceil 3.0 

O Flexent® TDMA Micro Cell for PCS Networks 

D Flexent® CDMA Micro Ceil for Cellular Networks 

O Flexent® CDMA Micro Cell for PCS Networks 

O Flexent® CDMA Mod Cell for PCS Networks 

O Series II Cell Site 

O CDMA/TDM A, AMPS/850/PCS, 2G, 3G 



Application Platforms 

O Intelligent Network Enhanced Control Server (eCS) 

C Intelligent Network Enhanced Media Resource Server 
(eMRS) 

C Intelligent Network Enhanced Services Manager (eSM) 
O Intelligent Network Compact Service Node (CSN) 



Mobile Applications and Service Delivery 

O MiLife"^ Intelligent Services Gateway (ISG) 
O MiLife^" Short Message Service Center 
O MiLife"^ SurePay® Solutions Suite 

Wireline Network 

Circuit Switch 

O 5ESS® Switch and 5E-XC'" Applications 
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O SE-XC^"^ Service Rich Software (5E16.1, 5E16.2, 
5E17.1) 

O 5ESS® Switch Very Compact Digital Exchange 
(VCDX®) 

O Distinctive Remote Module (DRM) 

O Access Interface Unit (AIU) 

O Access Interface Unit Expansion (EAIU) 

O Broadband Access Interface Unit (BAIU) 

O Multiplex Access Interface Unit (XAIU) 

O SM-2000 (Switching Module 2000) 

O One Link Administrative Service Module (ASM) 

O 5E-XC'" High Speed Trun king Optical Interface Unit 
IP / SIP (OIU - IP/SIP) 

O 5E-XC" High Capacity Switching with Communications 
Module 3 (CM-3) 

O Applications Processor TMS-5 and TMS-CDX 
O Packet Switch Unit - Unit 2E (PSU2E) 
O Dual Packet Switch Unit 
O Packet Switch Unit - SS7 
O Remote Line Unit (RLU-ESA) 

O Communications Assistance for Law Enforcement Act 
(CALEA) 

O Next Generation ISDN CPE Portfolio 
O Definity PBX 

Access Network 

O iMerge^" Centrex Feature Gateway 

O iMerge^" Network-based Call Signaling Gateway 

O Stinger'" DSL Access Concentrator Family 

VOIP 

O Lucent Network Controller (LNC) 

O Lucent Feature Server 3000 

O Cisco Call Manager H323 IP PBX 

O Session Initiation Protocol (SIP) Endpoints 

C Kagoor Networks'" VoiceFlow 1000 

Application Platforms 

O AnyPath'" Messaging System 
O Octel Voice Mail System 

O Intelligent Messaging Architecture - Caller Applications 
(IMA-CA) 

O ClientCare'" Call Center Deluxe Edition (DE) 

D Caller Application (CA) 

O Enhanced Business Services (EBS) 

O NavisRadius'" Authentication Server 

O Intelligent Network Enhanced Control Server (eCS) 

O Intelligent Network Compact Service Node (CSN) 

O Sierra Messaging System 

O Billdats Billing System 

O Recorded Announcements 

O E911 Analog & ISDN Public Safety Answering Points 
(PSAP) 

O Pinnacle ACD 

O E911 Service Adjunct (ESA) 



Miscellaneous Transmission Bay Equipment 
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O Telecom Solutions BITS Clock 

O Test Bus Control Unit 

O Pair Gain Test Controller 

O 17A, 16A, and 15A Recorded Announcement Units 

O Abacus, Ameritech, PROCALL, and MAGIC Call 
Generation Equipment 

Data Network 

Access Gateways 

O APX^"" 8000 Universal Gateway 

O MAX TNT® Universal Gateway 

O PacketStar® PSAX 1250 Multiservice Media Gateway 

O PacketStar® PSAX 2300 Multiservice Media Gateway 

O PacketStar® PSAX 4500 Multiservice Media Gateway 

O Ulticom Gateway 

O Cisco Media Gateway 

xDSL 

O AnyMedia® Access System (AMAS) 24 Channel uLaw 
O CellPIpe® IP Routers 

O Stinger^*^ ADSL/SDSL Access Concentrator Family 
O SuperLine^" Access System 

Routers 

O Juniper M-series Routers 

O Cisco Routers 

O DynaStar 500 Router 

O Cajun P550 Router 

O Cajun P333T Ethernet Switch 

O Xyplex Ethernet Switch 

Software 

O VitalSulte® Performance Management Software 
O VitalQIP^"^ DNS/DHCP IP Management Software 

ATM Core 

O CBX 500"" Multiservice WAN Switch 

O GX 550"" Multiservice WAN Switch 

O Springtide 7000 Wireless IP Services Switch 

Transport Network 

O Digital Access Cross-Connect System AX-11 (DACS AX- 
11) 

O Digital Access Cross-Connect System II (DACS II) 

O Digital Access Cross-Connect System IV (DACS IV) 

O Digital Data Multiplexer Plus (DDM Plus) 

O Digital Data Multiplexer 2000 OC-3 (DDM 2000 OC-3) 

O Digital Data Multiplexer 2000 OC-12 (DDM 2000 OC- 
12) 

O Digital Networking Unit - SONET (DNU-S) 

O DMX Access Multiplexer 

O Mercury Echo Canceller 

O Symphony - Echo Canceller 

O Cadenza - Echo Canceller 

O Cadenza II - Echo Canceller 

O Tekelec Eagle Signaling Transfer Points (STPs) 
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O D4 Channel Banks, Acculink Access System 

O Subscriber Loop Carrier (SLC) 96, 5, 2K, Connect 
Reach Fiber Reach 

Cable Network 

O ARRIS Cadant® C4^" Cable Modem Termination 
System (CMTS) 
O Motorola BSX 64000 CMTS 
O Cisco UBR 7200 CMTS 
O Other Vendors' Cable Softswitches 

O Arris Touchstone^'' Telephony Modems 202A 
Embedded Media Terminal Adapter (EMTA) 

O Arris Touchstone^"^ Telephony Modems 402P/NA-1 
EMTA 

O Terayon TA102 EMTA 
O Scientific Atlanta DBX2203 EMTA 
O Motorola SBU-5120 EMTA 
O Cisco MGX8800Trunking Gateway 
O Alopa Device Provisioning & Subscriber Management 
Software 

O VitalAccess^" Device Provisioning & Subscriber 
Management Software 

O Enterasys Matrix E and N Series Security Systems 
O Dragon GE500 Network Sensor 

Terms of use Privacy statement Agere Copyright © 2004 Lucent Technologies, Inc. All rights reserved. 
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1 . Lucent Outlines Softswitch Toll/Tandem Architecture for 3G 

2. OIF Adopts Two Very Short Reach (VSR) OC-192 Specs 

3. NEC America Introduces its Next Generation SONET/SDH Node 

4. Nortel Networks Releases MEMS-Based Tunable Filters 

5. Light Management Develops Acousto-Optic Switch 

6. Gigabit Optics announces 32-Channel Gi g abit Interface Transceiver 

7. Telia Raises ADSL Rates 

8. Alcatel Supplies 100K ADSL-lines to Deutsche Telekom 

9. NetStream Selects Cisco for MPLS Net 

10. 3Com Announces New Wireless LAN Solutions 

11 . Intel Acquires ICR vortex for Network Storage Technology 

LUCENT OUTLINES FLEXENT SOFTSWITCH TOLL/TANDEM ARCHITECTURE FOR 3G 

Lucent Technologies outlined an IP core architecture for 3G mobile networks that uses a softswit( 
APX 8000 VoIP gateway and PacketStar PSAX Multiservice media gateways to connect circuit-b; 
Mobile Switching Centers with IP or ATM backbones. In a second phase, Lucent plans to evolve 
Softswitch toll/tandem architecture center toward all-IP services run by a network of servers. Two 
elements will include the Lucent Flexent Mobility Server, open computing platform for managing 
mobility for the wireless packet core, and Lucent's Flexent Wireless Router, a high-performance r 
network controller based on cdma2000 and wideband CDMA. The Flexent Mobility servers will 
incorporate Sun's recently introduced line of Netra Compact PCI servers. Lucent's SpringTide 70 
Services Switch would be used for managing data traffic. 
http://www.lucent.com/press/0301/01Q320.nsc.html 
Lucent Technologies, March 20, 2001 

► In January, Lucent Technologies outlined its plans to pursue a service-intelligent network 
architecture in which business quality IP services are dynamically established through dire 
driven, policy-based provisioning of an IP services layer tied into MPLS signaling. Using 
"service intelligence" in the network, all elements in Lucenfs new IP network design would 
the capability to dynamically recognize and understand the needs of individual users and 
applications. Lucent intends to extend its service intelligent IP strategy throughout its entir 
product portfolio, including solutions from its wireless, data, optical, and software business 
units. A key element in the strategy will be Lucent's SpringTide IP Service Switches. 

► In December 1999, Sun Microsystems and Lucent Technologies announced a $500 millipr 
dollar alliance to develop an IP-based mobile network architecture based on Sun Netra se 
and Bell Labs-developed software. 

OIF ADOPTS TWO VERY SHORT REACH (VSR) OC-192 SPECS 

The Optical Internetworking Forum (OIF) adopted two more Very Short Reach (VSR) OC-192 inte 
specifications designed to reduce the cost of high-speed links between equipment in a single cen 
office (CO). Two "other VSR specifications had been adopted in January. The OIF's third VSR sp 
uses four 2.5 Gbps vertical cavity surface emitting lasers (VCSELs) in each direction on a single ' 
fiber ribbon (with 4 unused fibers). It has a reach of up to 300 meters. The solution maps the OC- 
frame onto the parallel optical link with no bandwidth expansion and no overwriting of the SONET 
overhead bytes. The OIF's fourth VSR spec utilizes a single 850-nanometer vertical cavity surfac 
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Pre-SPIRITS Implementations of PSTN-initiated Services 

Status of this Memo 

This memo provides information for the Internet community. It does 
not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 

Copyright Notice 

Copyright (C) The Internet Society (2000) . All Rights Reseirved. 
Abstract 

This document contains information relevant to the work underway in 
The Services in the PSTN/IN Requesting InTernet Services (SPIRITS) 
Working Group. It describes four existing implementations of 
SPIRITS -like services from Korea Telecom, Lucent Technologies, NEC, 
and Telia in cooperation with Nortel Networks. SPIRITS-like services 
are those originating in the Public Switched Telephone Network (PSTN) 
and necessitating the interactions of the Internet and PSTN. 
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□ 

RFC 2995 Pre-SPIRITS Implementations November 2000 

Surveying the implementations, we can make the following 
observations: 

ftp://ftp.rfc-editor.org/in-notes/rfc2995.txt 5/3 1/05 



o The ICW service plays the role of a benchmark service. All 
four implementations can support ICW, with three specifically 
designed for it. 

o Session Initiation Protocol (SIP) is used in most of the 

implementations as the base communications protocol between the 
PSTN and Internet. (NEC's implementation, is the only exception 
that uses a proprietary protocol. Nevertheless, NEC has a plan 
to support SIP together with the extensions for SPIRITS 
services . ) 

o All implementations use IN-based solutions for the PSTN part. 

It is clear that not all pre -SPIRITS implementations inter-operate 
with each other. It is also clear that not all SIP-based 
implementations inter-operate with each other given that they do not 



support the same version of SIP. It is a task of the SPIRITS Working 
Group to define the inter-networking interfaces that will support 
interoperation of the future implementations of SPIRITS services. 
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1. Introduction 

This document contains information relevant to the work underway in 
The Services in the PSTN/IN Requesting InTernet Services (SPIRITS) 
Working Group. It describes four existing implementations of 
SPIRITS-like services from Korea Telecom, Lucent Technologies, NEC, 
and Telia in cooperation with Nortel Networks. SPIRITS-like services 
are those originating in the Public Switched Telephone Network (PSTN) 
and necessitating the interactions of the Internet and PSTN. 

Invariably supported by the implementations examined in this document 
is the Internet Call Waiting (ICW) service. With ICW, service 
subscribers, while using their telephone lines for Internet access, 
can be notified of incoming voice calls and specify how to handle the 
calls over the same telephone lines. 
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□ 

RFC 2995 Pre-SPIRITS Implementations November 2000 

The document first gives a detailed description of the ICW service. 
Then it proceeds to discuss each of the four implementations. The 
final sections of the document contains security considerations, the 
conclusion and references. 

It is important to note that even though the term "SPIRITS server" is 
used throughout the document, it has no universal meaning. Its 
connotation depends on the context and varies from implementation to 
implementation . 

2. Service Description of Internet Call Waiting 

Internet call waiting is the single service that is specifically 
supported by all the implementations in question. In a nutshell, the 
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service enables a subscriber engaged in an Internet dial-up session' 
to 

o be notified of an incoming call to the very same telephone line 
that is being used for the Internet connection; 

o specify the desirable treatment of the call; and 



o have the call handled as specified. 



The details of the ICW service lie in the ways that a waiting call 
can be treated, which vary from implementation to implementation. In 
this section, we describe the features that are supported by at least 
one of the implementations. They are as follows: 

o Incoming Call Notification - The subscriber is notified of an 

incoming call over the Internet, without having any effect on the 
telephone line that is being used by the modem. When a call, comes 
in, the subscriber is presented with a pop-up dialog box on the 
PC. The dialog box may display any combination of the calling 
party number, calling party name, and calling time. Note that the 
display of the calling party name (or number) requires the 
availability of the caller name (or number) delivery feature. 

o Online Incoming Call Disposition - Once informed of the incoming 
call, the subscriber has various options (indicated in the pop -up 
window) for handling the call. Possible options are: 

+ Accepting the call over the PSTN line, thus terminating the 
Internet (modem) connection 

+ Accepting the call over the Internet using Voice over IP (VoIP) 



+ Rejecting the call 
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+ Playing a pre-recorded message to the calling party and 
disconnecting the call 

+ Forwarding the call to voice mail 

+ Forwarding the call to another number 

+ Rejecting (or Forwarding) on no Response - If the subscriber fails 
to respond within a certain period time after the dialog box has 
been displayed, the incoming call can be either rejected or 
handled based on the treatment pre-defined by the subscriber. 

o Automatic Incoming Call Disposition - Incoming calls are 

automatically handled based on dispositions pre-defined by the 
subscriber without his or her real-time intervention. The 
subscriber can pre-define the default disposition (e.g., re- 
directed to voice mail) for general calls as well as customized 
dispositions for calls from specific numbers. In the latter case, 
the subscriber selects a particular disposition for each 
originating number and stores this information in a profile. When 
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a call comes in, the subscriber won't be presented the call but 
can examine the treatment and outcome of the call from the caller 
log (as described in the call logging bullet) . Naturally, this 
feature also allows the subscriber to specify the desired 
treatment for calls originating from private or unpublished 
numbers . 

o Multiple Call Handling - Multiple calls can arrive during call 
disposition processing. With multiple call handling, the 
subscriber is notified of the multiple calls one by one. 

o Call Logging - A detailed log of the incoming calls processed 
during the ICW service is kept. Typical information recorded in 
the log include the incoming call date and time, calling party 
number, calling party name, and call disposition. 

3. Korea Telecom's ICW Implementation 

3.1. Overview 

Korea Telecom's ICW implementation supports most of the features 
described in Section 2. (The major exception is the feature of 
receiving the incoming call over the Internet using voice over IP.) 
In addition, the Korea Telecom implementation supports flexible 
activation and de-activation of the ICW service: 



Lu, et al . Informational [Page 5] 



o Automatic Activation/De -activation - When Internet dial-up 

connection is set up, the ICW service is activated or de-activated 



o Manual Activation/De-activation - The subscriber can de-activate 
the ICW service manually when call notification is not desired 
during the Internet dial-up session and activate it when needed. 

3.2. Network Architecture 

Figure 1 depicts the network architecture of the Korea Telecom ICW 
service. The Service Switching Point (SSP) , Service Control Point 
(SCP) , and Intelligent Peripheral (IP) are legacy PSTN IN elements 
based on IN CS-1. In contrast, both the ICW Server System and the 
ICW Client System are new network elements that are installed in the 
Internet domain to support of the ICW service. 

+ + I ^ + 

1+ +propr- + +1 PINT j | (Proxy Server) | PINT 

I I (ICW SL) |ietary| (UAC/UAS) I I -|i j ICW | + 

j jsCF/SDF I I SCGF j j firewall [Server System | | 

j4 + i/f + 4| I ^ _ ^ I 
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Figure 1: Network Architecture of the Korea Telecom ICW Service 
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3.3. Network Entities 

3.3.1. SSP 

The SSP performs the Service Switching Function (SSF) and Call 
Control Function (CCF) . When detecting that the called party is busy 
(T_Busy) , the SSP sends a query to the SCP and processes the call 
under the control of the SCP. 

3.3.2. SCP 

The SCP performs the Service Control Function (SCF) and Service Data 
Function (3DF) . It, when queried, instructs the SSP to process the 
call based on the service logic. In the case of the ICW service, the 
service logic ultimately governs the notification of a waiting call 
to an online ICW. subscriber and the disposition of the call. In 
addition, the SCP performs the Service Control Gateway Function 
(SCGF) for protocol inter-working between the PSTN/IN and Internet. 
It translates the SIP message from the ICW Server to the service 
control interface message and vise versa. The SCGF is an IP end 
ipoint and behaves as a UAS (User Agent server) or UAC (User Agent 
client) . 

3.3.3. IP 

The IP contains Service Resource Function (SRF) . It, when necessary, 
plays announcements to the calling party during the ICW service 
before/after receiving- the response from the ICW subscriber and 
records the calling party number or voice message from the calling 
party v;hen the call is forwarded to the V^oice Mail System (VMS). 

3.3.4. ICW Server System 
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The ICW Server system serves as a SIP proxy or a redirect server for 
message routing between the ICW Client and SCGF. The ICW Server is 
also responsible for managing the ICW Clients that are connected to 
it. When an ICW Client (subscriber) sends a registration request for 
the ICW service, the ICW Server relays that request to the SCP, waits 
for the result of authorization from the SCP, and registers the 
authorized subscriber in its data base. In addition, the ICW Server 
monitors the connection status of the registered ICW Clients. As 
soon as a client deactivates the ICW seirvice or terminates the 
Internet connection, the ICW Server detects the status change and 
deactivates the ICW service for the client. Finally, the ICW Server 
manages profiles for each ICW subscribers as well as logs all the 
call processing results. 
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3.3.5. ICW Client System 

The ICW Client System is an application program running on the 
subscriber's PC. Launched as soon as the subscriber powers on the 
PC, it monitors the Internet connection status of the PC (or 
subscriber). Upon the subscriber's connection to the Internet, the 
ICW Client sends a REGISTRATION request to the SCGF via the ICW 
Server and then eventually to the SCP. In this capacity, the ICW 
Client acts as a UAC to the SCGF, which acts as a UAS . Thereafter it 
notifies the ICW Server periodically of the connection status of the 
subscriber . 

The ICW Client is also responsible for popping up a dialog box on the 
subscriber's PC to announce an incoming call. The dialog box 
displays the number and name of calling party, calling time, and the 
call processing options (including Accept, Reject, Forward to another 
number or VMS) . After the subscriber selects the option, the ICW 
Client sends it to the SCP. In this capacity, the ICW Client acts as 
a UAS. 

Depending on the pre-defined ICW Service Profile, the ICW Client may 
screen the incoming call before notifying the subscriber. 

The ICW Client manages the ICW Service Profile, which contains the 
following fields: 

o Subscriber Information (including. Name, Directory Number, 
Password) 

o Service Status (Activation/De -activation) 

o Automatic Call Processing Method 

+ Call Processing Method on No Answer (Reject/Forward/VMS) - The 
call is automatically handled by the method if the subscriber 
doesn't respond after a pre-defined period of time. 

+ Do Not Disturb Mode (On/Off) - When this is set on, the subscriber 
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won't be notified of the incoming calls. 

+ Call Processing Method on Do Not Disturb {Re j ect/Forward/VMS) 

+ Call Processing List by Calling Party Numbers 

(Accept/Re j ect/Forward/VMS) - Calls originated from a number on 
the list are handled by the associated call processing method. 

o The ICW Client records the call processing method and the result 
for each incoming call in a log file on the subscriber's PC. The 
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call record in the call log contains the following information: 

- Calling Time 

- Calling Party Number 

- Calling Party Name (optional) 

- Call Processing Method (Accept/Re ject /Forward/Forward to VMS) 

- Result (Success/Fail) 

3.3.6. Firewall 

Packet Filtering Firewall Systems are between the ICW server and 
clients as well as between the SCGF and ICW server for accessing the 
Korea Telecom IN Nodes . 

3.4. Network Interfaces 

o The SCF-SDF, SCF-SSF, and SCF-SRF interfaces are the same as 
existing PSTN IN Interfaces based on the KT INAP CS-1. 

o The SCGF-SCF interface relays requests either from the IN or the 
Internet and is implemented based on the internal API of the SCP. 

o The SCGF-ICW Server and ICW Server-ICW Client interfaces are 
implemented based on the PINT Service Protocol V.l. We adopted 
UAS-Proxy-UAC relationships as shown in Figure 2. 

+ + + + + + 

I (UAC/UAS) |PINT 1.0 I (Proxy) | PINT 1 . 0 | (UAC/UAS) | 

j I I ICW I I ICW I 

I SCGF I I Server | | Client | 
+ + + + + + 

Figure 2 : PINT Protocol Architecture 

3.5, Protocols 

3.5.1. Intelligent Network Application Part Protocol (INAP) 

The SCP, SSP, and IP support the KT INAP VI . 0 , which is based on 
ITU-T INAP CS-1 with the incorporation of two INAP CS-2 messages [PRM 
(PromptAndReceiveMessage) and EM (EraseMessage) ] for recording the 
voice message. 

3.5.2. PINT Protocol 
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The ICW service uses the PINT Service Protocol 1.0 [1] for 
communications between the SCP and the ICW Server System, and between 
the ICW Server System and the ICW Client System. Developed in the 
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IETF PINT Working Group for invoking telephone services from an IP 
network, the PINT Service Protocol 1.0 specifies a set of 
enhancements to SIP 2.0 and SDP . 

Summarized below are the elements of the PINT Service Protocol 1.0 
relevant to the Korea Telecom ICW implementation: 

o REGISTER 

The REGISTER method is used to inform the SCP of the connection 
status of an ICW subscriber. With this method, the ICW Client 
sends to the ICW Server the IP address (of the PC) and phone 
number of the subscriber when the subscriber is first connected to 
the Internet. The ICW server relays the information to the SCP, 
which updates the data base (if the subscriber is authorized), and 
in the end sends a registration acknowledgment to the ICW Server 
and then the Client. After the subscriber is connected to the 
Internet, the ICW Client sends a REGISTER request to the ICW 
Server periodically at a pre-defined interval (e.g., 20 seconds) 
to indicate its connection status. The request is not relayed to 
the SCP. The ICW Server only checks if it is from the authorized 
subscriber. Finally, when the subscriber terminates the Internet 
connection, the Client sends the last REGISTER request to the SCP 
via the ICW Server. If the REGISTER request, does not arrive 
during the pre-defined interval, the ICW Server can also detect 
the change of the connection status of the ICW Client. 

O INVITE 

The SCP uses the INVITE method to notify the ICW Client, via the 
ICW Server, of an incoming call. 

o ACK 

Both the SCP and the ICW Server use the ACK method to confirm the 
receipt of the final responses to their requests. 

o BYE 

The BYE method terminates a ser\rice session. In addition to this 
original usage, we use the value (success or failure) of the 
Subject header to indicate the result of the desired disposition 
of an incoming call in the PSTN. 
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o CANCEL 



When the calling party releases the call before the called party- 
responds, the SCP sends a CANCEL request to the ICW Client to 
cancel the INVITE request that it sent previously. 

o OPTION 

This method is not used in the KT implementation, 
o Responses 

The SCP responds to a REGISTER request with one of the status 
codes and associated comments below: 

. 100 Trying: Trying 
. 200 OK: Registered 

The ICW Client responds to an INVITE request with one of the 
status codes and associated comments below: 

. 100 Trying: Trying 

. 200 OK: Accept the Call 

. 303 see other: Forward the Call to Another Number 

. 380 alternative service: Forward the Call to the VMS 

. 603 decline: Reject the Call j 

3.6. Example Scenarios r 

3.6.1. ICW Service Subscription 

Access to the Korea Telecom ICW service is by subscription. Here 
Korea Telecom serves as both the PSTN operator and IN-based ICW 
service provider. Note that the subscription data need to be loaded 
onto the relevant SSPs, including the local ones that may not be 
operated by Korea Telecom. 

3.6.2. ICW Client Installation 

An ICW subscriber should install the ICW Client program in his or her 

PC. The ICW Client is automatically activated to run as a daemon 

process when the subscriber's PC is turned on. The Client monitors 
the Internet connection status of the subscriber. 



Lu, et al. Informational [Page 11] 



□ 

RFC 2995 



Pre -SPIRITS Implementations 



November 2 000 



ttp://flp.rfc-editor.org/in-notes/rfc2995.txt 



5/31/05 



3.6.3. ICW Service Activation 



When the subscriber initiates the Internet connection or activates 
the ICW service manually, the ICW service is activated. That is done 
by sending a REGISTER request with the directory number and IP 
address from the ICW Client to the SCP through the ICW Server. 



ICW Subscriber ICW Server 
ICW Client 
(DNl/IPl) (IP2) 



OA 

0BREG(DN1, IPl) 



SCGF 

(IP3) 

I 

I 
I 



SCF/SDF 

I 
I 

I 



SSF/CCF 



200 OK 5A 



-> |REG(DN1, IPl) I 

I ,| I 

I 2A I 
I |reg{DNl,IPl) | 

I _._._>! 

I I 3A 

I I reg ok 3B 

I 

I 200 OK 4A I 
I I 

I I 

I I 



6A 



Calling 
party 
(DN2) 



> PINT Protocol 

--.--> INAP Protocol 
=====> Bearer 



-.-.-> SCP Internal API 
+++++> ISUP Protocol 



Figure 3: ICW Service Activation 

As depicted in Figure 3, the relevant information flows are as 
follows: 

(OA) The ICW subscriber dials the ISP access number and establishes a 
PPP connection. 

(OB) The ICW Client detects the PPP connection. 

1. The ICW Client sends a registration request to the ICW Server in 
order to register the IP address -DN relationship for the dial-up 
connection. 



2. The ICW Server relays registration request to the SCGF. 
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2A. The SCGF translates the user registration information from the 
SIP message to the SCP internal API message. 

3. The SCGF relays the user registration message to the SCF/SDF. 
3A. The SCF/SDF authorizes the subscriber with the directory number 
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based on the user registration information. 

3B. The SCF/SDF stores the IP address of the ICW Client and sets the 
status to "Internet on-line." 

4. The SCF/SDF sends the result of registration to the SCF/SCGF. 

4A. The SCGF translates the user registration response of the SCP 
internal API message to the PINT message. 

5. The SCGF relays the user registration response to the ICW Server. 

5A. The ICW Server records the user registration information and the 
Internet on-line status for the subscriber in the data base. 

6. The ICW Server sends the user registration response to the ICW 
Client . 

6A. The ICW Client notifies the subscriber that the registration is 
completed successfully and the; ICW service is in the active state. 
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3.5.4. Incoming Call Notification 

When a calling party makes a call to the ICW subscriber, the SCP 
notifies the ICW Client of the incoming call and waits for the 
subscriber's response. 
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Figure 4 : Incoming Call Notification 



As depicted in Figure 4, the relevant information flows are as 
follows : 

1. The calling party at DN2 (a telephone user) makes a call to the 
ICW subscriber (PC user) at DNl. The connection is set up using the 
existing ISDN signaling. 

lA. The SSF/CCF detects that the callee (the ICW subscriber) is busy. 



Lu, et al. Informational [Page 14] 



2. The SSF/CCF sends InitialDP (T_Busy) to the SCF/SDF. 

2A. The SCF/SDF determines whether the user at DNl is PSTN on-line or 
Internet on-line. (The SCF/SDF executes the KT Telephone Mail 
Service logic in the PSTN on-line case and the ICW service Logic in 
the Internet on-line case.) 

2B. The SCF/SDF retrieves the IP address corresponding to DNl. 

2C. The SCF/SDF may play an announcement to the calling party, while 
waiting for the response of the called party. 

3. The SCF sends an incoming call notification to the SCGF. 

3A. The SCGF translates the incoming call notification from the SCP 
internal format to the PINT format . 

4. The SCGF relays the notification to the ICW Server. 
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4A. The ICW Server double-checks the subscriber's status using the 
ICW subscribers profile in its own data base. 

5. The ICW Server sends trying message to the SCGF. 

6. The ICW Server relays the notification to the ICW Client. 

6A. The ICW Client consults the ICW service profile to see if there 
is a pre-defined call disposition for the incoming call. If so, then 
the procedure for automatic call processing is performed. 

6B. If there is no pre-defined call disposition for the incoming 
call, the subscriber is notified of the call via a pop-up dialog box. 

7. The ICW Client sends trying message to the ICW Server. 

3.6.5. Incoming Call Processing 

The incoming call can be accepted, rejected, forwarded to another 
number, or forwarded to the VMS depending on the on-the-fly or pre- 
defined choice of the subscriber. This section describes the 
information flows for the cases of "Accept the call" and "Forward the 
call to another number." 
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3.5.5.1. Accept the Call 
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Bearer 

Figure 5: Incoming Call Processing - Accept the Call 

As depicted in Figure 5, the relevant information flows are as 
follows : 

OA. The ICW subscriber chooses to "Accept" the incoming call. 

1. The ICW Client sends the "Accept" indication to the ICW Seirv^er. 

lA. The ICW Client records the subscriber's selection for the 
incoming call in the call log. 
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IB. The ICW Client terminates the subscriber's Internet connection. 

2. The ICW Server sends an "Accept" message to the SCGF. 

2A. TJie SCGF translates the "Accept" message to an SCP internal API 
message. 

3. The SCGF sends an "ACK" message to the ICW Server. 

4. The SCGF sends the "Accept" message to the SCF. 

5. The SCF instructs the SSF/CCF to route the call to DNl . 

6. The SSF/CCF initiates the connection setup to DNl. 

6A. The bearer connection between the calling party (DN2) and the ICW 
subscriber (DNl) is set up. 

7. The connection result is returned to the SCF through ERB. 

8. The SCF sends a call completion message to the SCGF. 

8A. The SCGF translates the call completion message to a PINT 
message . 

9. The SCGF sends a "BYE"' message to the ICW Server. 

9A. The ICW Server records the call completion result in the log 
file. 
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3.5.5.2. Forward the Call to Another Number 
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Figure 6: Incoming Call Processing - Forward the Call to Another 
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As depicted in Figure 6, the relevant information flows are as 
follows : 

OA. The ICW subscriber chooses to "Forward to another number (DN3)" 
for the incoming call . 

1. The ICW Client sends the "Forward to another number" indication to 
the ICW Server. 

lA. The ICW Client records the subscriber's selection for the 
incoming call in the call log. 
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2. The ICW Server sends an "ACK" message to the ICW Client. 

3. The ICW Server relays the "Forward to another number" message to 
the SCGF. 

3A. The SCGF translates the "Forward to another number" message to an 
SCP internal API message. 

4. The SCGF sends an "ACK" message to the ICW Server. 

5. The SCGF sends the "Forward to another number" message to thei SCF. 

6. The SCF instructs the SSF/CCF to route the call to DN3 . 

7. The SSF/CCF initiates the connection setup to DN3 . 

7A. The bearer connection between the calling party (DN2) and the new 
termination number (DN3) is set up. 

8. The connection result is returned to the SCF through ERB. 

9. The SCF sends a call completion message to the SCGF. 

9A. The SCGF translates the call completion message to a PINT 
message. 

10. The SCGF sends the call completion message to the ICW Server. 

lOA. The ICW Server records the call completion result in the log 
file. 

11. The ICW Server sends the success of "Forwarding to another 
number" to the ICW Client. 

IIA. The. ICW Client records the call completion result in the log 
file. 
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3.6.6. ICW service De-activation 

The SCP de-activates the ICW service for a subscriber either upon the 
termination of the subscriber's Internet connection or upon the 
subscriber's manual request. In this section, we illustrate the 
former scenario. 



ICW Subscriber ICW Server SCGF 
ICW Client 
(DNI/IPI) (IP2) (IP3) 

I I I 

OA I I 

OB I 

|Unreg{DNl, IPl) 
I >| 

I lA 



SCF/SDF 



j 200 OK 



|Unreg{DNl, IPl) 
|-.-.-.-.-.->| 
I 2A 
2B 



ok 



l<- 
3A 

I 



4A 



SSF/CCF 



Calling 
party 
(DN2) 



> PINT Protocol -.-.-> SCP Internal API 

--.--> INAP Protocol +++++> ISUP Protocol 

====:=> Bearer 

Figure 7: ICW Service De-activation 

As depicted in Figure 7, the relevant information flows are as 
follows : 

OA. The ICW subscriber terminates the Internet connection. 

OB. The ICW Server determines that the Internet connection has been 
terminated when it does not receive the periodic on-line notification 
from the ICW Client. 

1. The ICW Server sends an un-register message to the SCGF. 

lA. The SCGF translates the un-register message to an SCP internal 
API message. 
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2. The SCGF sends the un-register message to the SCF. 

2A. The SCF/SDF authorizes the subscriber with the directory number 
based on the un-registration information. 

2B. The SCF/SDF records the Internet off-line status for that ICW 
Client. 

3. The SCF/SDF sends a user un-registration response to the SCF/SCGF. 

3B. The SCGF translates the user un-registration response to a PINT 
message. 

4 . The SCGF relays the user un-registration response to the ICW 
Server . 

4A. The ICW Server records the Internet off-line status for the ICW 
Client (subscriber) in the data base. 

4. The Lucent Technologies Online Communications Center 

4 . 1 Overview 

The Lucent Technologies Online Communications Center (OCC) is an 
Intelligent Network (IN) -based platform that supports the Internet 
call waiting service. Its basic components are the OCC Server and 
OCC Client, which are described in detail in the Architecture 
section. The OCC Server interacts with the PSTN entities over the 
secure intranet via plain-text Session Initiation Protocol (SIP) 
messages [2] . With the PC Client, the OCC Server interacts via 
encrypted SIP messages. 

The OCC Server run-time environment effectively consists of two 
multi -threaded processes responsible for Call Registration and Call 
Notification services, respectively. 

OCC call registration services are initiated from an end-user's PC 
(or Internet appliance) . With those, a subscriber registers his or 
her end-points and activates the notification services. (The 
registration services are not, strictly speaking, SPIRITS services 
but rather have a flavor of PINT services.) 

All OCC call notification services are PSTN-initiated. One common 
feature of these services is that of informing the user of the 
incoming telephone call via the Internet, without having any effect 
on the line already used by the modem. (A typical call waiting tone 
would interrupt the Internet connection, and it is a standard 
practice to disable the "old" PSTN call waiting service for the 
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duration of the call in support of the Internet connection between 
the end-user and the ISP.) 

When a call comes in, the user is presented with a pop-up dialog box, 
which displays the caller's number (if available), name (again, if 
available), as well as the time of the call. If the called party- 
does not initiate an action within a specified period of time the 
call is rejected. 

As far as the disposition of the call is concerned, OCC supports all 
the features described in Section 2. 

4.2. Architecture 
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Figure 8 r The Lucent OCC Physical Architecture 

Figure 8 depicts the joint PSTN/Internet physical architecture 
relevant to the OCC operation. The Compact Service Node (CSN) and 
SCP are Lucent's implementations of the ITU-T IN Recommendations (in 
particular, the Recommendation Q.12 05 where these entities are 
defined) augmented by the requirements of Bellcore's Advanced 



Lu, et al . Informational tPage 22] 

□ 

RFC 2995 . Pre-SPIRITS Implementations November 2000 



Intelligent Network (AIN) Release 1.0) and equipped with other 
features. The Central Office (CO) may be any switch supporting the 
Integrated Services Digital Network (ISDN) Primary Rate Interface 
(PRI) and the call forwarding feature that would allow it to 
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interwork with the CSN. Alternatively, in order to interwork with 
the SCP, it needs to be an IN Service Switching Point (SSP) . In the 
latter case, the central office is connected to the SCP via the 
signaling system No. 7 (SS7) and INAP at the application layer. 



The Service Management System (SMS) is responsible for provisioning 
of the SCPs, CSNs, and central offices. In particular, for IN 
support of the Internet Call Waiting, it must provision the Central 
Office to direct a terminating attempt query to the subsystem number 
corresponding to the OCC SCP SPA based on the Termination Attempt 
Trigger (TAT) . In addition, the Subscriber Directory Number (DN) , 
Personal Identification Number (PIN) and Language ID are provisioned 
for each subscriber into the OCC Subscriber entry of the SCP Real 
Time Data Base (RTDB) . Figure 9 shows the structure of an RTDB 
entry. 

+ + 

|DN I PIN I IP Address | Session Key | CNF | Language ID | 
+ + 

Field Descriptions: 



(DN) Directory Number - the subscriber's telephone number 

(PIN) Personal Identification Number - the subscriber's password 

IP Address - Internet Protocol Address of the subscriber 

(CNF) Call Notification In Progress Flag (boolean) - the flag 
indicating if an attempt to notify the subscriber of a call is 
currently in progress 

Session Key - unique identifier for the current registration session 
of the subscriber 



Language ID - language identifier for the subscriber 

Figure 9 : Structure of the RTDB Subscriber Record 

The Central Office, SMS, CSN, and SCP are the only PSTN elements of 
the architecture. The other elements are VoIP Gateway and Gatekeeper 
defined in the ITU-T Recommendation H.323, whose roles are to 
establish and provide the part of the voice path over IP. The 
Central Office is explicitly connected to the VoIP Gateway via the 
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ISDN PRI connection. In this architecture,. CSN, VoIP Gateway, and 
VoIP Gatekeeper are the only entities connected to the Internet, with 
each respective connectipn protected by a firewall. The CSN and SCP 
are interconnected via a secure IP Intranet . There may be more than 
one CSN or SCP (or both) (and the SCPs come in mated pairs 
Interconnected by X.25,- anyway) in a network, but these details are 
not essential to the level of description chosen for this document. 
However, we note that load balancing and adaptation to failures by 
the use of alternative nodes is incorporated into the architecture.. 
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When someone attempts to call the subscriber, the central office 
serving that subscriber interrupts normal termination processing and 
notifies the SCP which, in turn, can check whether that subscriber 
has registered that he (or she) is logged onto the Internet. 
Exploiting the standardized layering of service logic that 
characterizes the intelligent network, the central office will do 
this without requiring the installation or development of any central 
office software specific to OCC. The central office is simply 
provisioned to query the SCP when there is a termination attempt 
(i.e., TAT) directed to the subscriber's directory number. (Note 
that the Central Office has no bearer circuit connection to the SCP, 
only a signaling- one over SS7) . 

TCP/IP communication between the SCP and CSN utilizes a secure 
intranet. The subscriber, of course, is assumed to have access only 
to the Internet . 

The intelligent network entities, the SCP and CSN, do have OCC 
related software. The OCC server is implemented on the CSN. In 
addition, one service package application (SPA) is installed on the 
SCP. Another SPA is located in the CSN and is needed only when the 
subscriber elects to accept an incoming call using voice over IP. 

The OCC Server is a collection of Java servers on the CSN whose 
responsibilities include: 

o Listening for incoming Call Notification (TCP/IP) messages from 
the SCP SPA. 

o De-multiplexing/multiplexing incoming Call Notification messages 
sent from the SCP SPA. 

o Relaying messages between the OCC Client and the SCP SPA. 

o Listening for and authentication of OCC Client requests for 
service registration. 
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o Handling encryption/decryption of messages exchanged with the OCC 
Client, and generating session-specific encryption/decryption 
keys . 

The OCC Client is a collection of software components that run on the 
Subscriber's PC. Its components include the SIP User Agent Server 
(which handles the exchange of SIP messages with the OCC Server and 
invokes the Call Notification pop-up window) and a daemon process 
that monitors the Point -to-Point Protocol (PPP) actions and is 
responsible for starting and stopping the SIP User Agent Server. 

4.3. Protocol and Operations Considerations 

The OCC Server uses distinct TCP/IP ports configured on the CSN to 

o Listen for incoming SIP REGISTER messages (in support of 
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registration service) sent from the OCC Client. 

o Listen for incoming SIP INVITE messages (in support of call 
notification service) sent from the SCP. 

During call notification, the SCP SPA is the client and thus is 
started after the OCC Server has been started. The SCP SPA and OCC 
Server exchange SIP messages over TCP/IP (via the Secure Intranet) 
using a "nailed-up" connection which is initiated by the SCP SPA. 
This connection is initiated at the time the SCP SPA receives the 
very first SIP REGISTER request from the OCC Server, and must prevail 
for as long as the SPA is in the in-service state. The SCP SPA also 
supports restarting the connection after any failure condition. 

The OCC Server supports multithreading. For each Call 
Notif ication/Call Disposition event, a separate thread is used to 
handle the call. This model supports multi-threading on a "per 
message" basis where every start message (SIP INVITE) received from 
the SCP SPA uses a separate thread of control to handle the call. 
Subsequent messages containing the same session Call-ID (which 
includes the SPA's instance known as "call_index" and the SCP 
hostname) as the original start message is routed to the same thread 
that previously handled the respective initiating message. 

The OCC Server dynamically opens a new TCP/IP socket with the OCC 
Client for each Call Notification/Call Disposition session. This 
socket connection uses the IP address and a pre-conf igured port on 
the PC running the OCC Client software. 

For session registration, the OCC Server dynamically opens TCP/IP 
sessions with the SCP SPA. The SCP SPA listens at a pre-conf igured 
port to incoming SIP REGISTER messages sent by OCC Clients via the 
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OCC Server. To exchange SIP messages with the OCC Server, the OCC 
Client dynamically opens a TCP/IP socket connection with the OCC 
Server using a pre-conf igured port number on the CSN and the CSN's IP 
address . 

For the VoIP Scenario, the CSN SPA, acting as a client, dynamically 
opens TCP/IP sessions with che SCP that handled the initial TAT 
query. As soon as the CSN SPA has successfully made the correlation 
and connected the two incoming call legs pertaining to a VoIP call 
back, the SIP 180 RINGING message will be sent back to the SCP SPA 
running on the actual SCP that instructed the SSP to forward the 
Caller to the CSN. This SIP message, which contains the VoIP Call 
Back DN dialed by one of the bridged call legs, is an indication t:o 
the SCP SPA that the VoIP Call Back DN is freed up. 

A typical subscription scenario works like as follows: 

1. Each VoIP Gateway is provisioned with a list of authorized VoIP 
Call Back. DNs, each terminating on a particular CSN. These 
apecial DNs are used when an on-line subscriber elects to receive 
an incoming call via VoIP. In particular, they assist in routing 
an outgoing call from the subscriber's NetMeeting to the 
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particular CSN to which the SCP is (roughly concurrently) 
forwarding the incoming call. (These two calls are joined in the 
CSN to connect the incoming call to the subscriber's Netmeeting 
client.) Furthermore, these special DNs permits that CSN to 
associate, and hence bridge, the correct pair of call legs to join 
the party calling the subscriber to the call from the subscriber's 
NetMeeting client. 

2 . The subscriber calls a PSTN service provider and signs up for the 
service . 



3. An active Terminating Attempt Trigger (TAT) is assigned to the 
subscriber's DN at the subscriber's central office. 



4 . The PSTN service provider uses the SMS to create a record for the 
subscriber and provision the Subscriber DN and PIN in the OCC RTDB 
table in the SCP. 

5. The subscriber is provided with the OCC Client software, a PIN and 
a file containing the OCC Server IP Addresses. 

Finally, we describe the particular scenario of the OCC Call 
Disposition that involves voice over IP, which proceeds as follows: 

1. The OCC subscriber clicks on "Accept VoIP". 
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2. The OCC Client sends a "SIP .380 Alternative Service" message to 
the OCC Server. This message includes a reference to the Call 
Back DN which will ultimately be used by the CSN to associate the 
call leg (soon to be initiated by the subscriber's NetMeeting) 
connecting to the subscriber (via the VoIP gateway) with the PSTN 
call leg connecting to the calling party. 

3. The OCC Server closes the TCP/IP session with the OCC Client and 
sends to the SCP SPA the "SIP 380 Alternative Service" message 
which includes the Call Back DN. 

4. The SCP SPA instructs the Central Office to forward the call 
incoming to the subscriber to the CSN. This instruction includes 
the Call Back DN. 

5. The SSP forwards the Caller to the CSN referencing the Call Back 
DN. Note that the Call Back DN, originally assigned to the OCC 
client by the SCP when the subscriber was alerted to the presence 
of an incoming call attempt, flowed next to the OCC server when 
the client elected to receive the call via VoIP, then to the SCP., 
then to the central office in association with a SCP command to 
forward the incoming call to the CSN, then to the OCC server on 
the CSN in association with that forwarded call. 

c. Meanwhile, the OCC Client extracts 1) the VoIP Call Back DN from 
the SIP INVITE message received during Call Notification and 2) 
the H323UID and H323PIN values from its properties file and 
updates the 'netmtg.cnf' file. 
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7. The NetMeeting application is launched and sets up a connection 
with the VoIP Gateway. 

8. Once a connection is established between NetMeeting and the VoIP 
Gateway, NetMeeting initiates a phone call - passing to the VoIP 
Gateway the Call Back DN as the destination DN. 

9. The VoIP Gateway consults the VoIP Gatekeeper and authenticates 
the NetMeeting call by verifying the H323UID and H323PIN values, 
and by ensuring the called DN (i.e., Call Back DN) is authorized 
for use. 

10. After passing the authentication step, the VoIP Gateway dials 
(via PSTN) the Call Back DN and gets connected to the CSN. The 
CSN notes that it was reached by the particular Call Back DN. 

11. The CSN bridges the Calling and Called parties together by 
matching on the basis of the Call Back DN. 
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12. The CSN notifies the SCP (SIP 180 Ringing) of status and 
references the Call Back DN so that the SCP can reuse it for 
other calls. 

13. If the central office supports that two B-channel transfer 
(Lucent, Nortel, and perhaps other central office vender's do), 
an optimization is possible. The CSN can have the central office 
rearrange the topology of the newly connected call in such a way 
that it flows only through the central office and no longer, 
through the CSN. 

5. NEC's Implementation 

5.1. Overview 

The NEC implementation of the ICW service is based on IN. Via a 
SPIRITS server and an ICW client, incoming calls will be presented to 
the user via a pop -up screen dialogue box. This dialogue box informs 
the user of the call arrival time and the calling party's number and 
name (if available) . The arrival of the call is also indicated with 
an accompanied audible indication. 

The pop-up dialogue box offers the user various call management 
options. Selecting a call management option allows the user to 
answer the call, forward it to another destination or to voice mail, 
or ignore it . 

The user will be able to customize their service through various 
service set-up options. All calls presented to the user during an 
Internet session will be recorded in a call log. 

other features include Multiple call arrival management with which 
each new call arrival will generate its own pop-up dialogue box and 
audible indication. 
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5.2. Architecture and Overall Call Flow 
Figure 10 depicts the NEC ICW system. 
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Traffic : 



SSP : Service Switching Point 
CO : Central Office 
M/D : Modem 



PSTN Voice Traffic 
PPPdP traffic) 
Signaling Traffic 
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Interfaces : 



pO 

Pl 
p2 

P3 
p4 



SPIRITS Server-SCP (SPIRITS Client) interface 
SPIRITS Server-ICW Client interface 
ICW Client -W3S interface 
(Web access through HTTP) 
SCP-SSP interface (INAP) 
SSP-CO interface (ISUP) 



Figure 10: the NEC ICW system 



The description below provides the necessary steps to initiate the 
ICW service on a CO line, and how the ICW service is applied to an 
incoming call based on the above architecture: 

1. The CO line is primed for the ICW service when the customer 
connects to their ISP by inserting a special activation code 
(e.g., *54) prefix in front of the ISP Directory Number. 

2 . The ICW service is activated when the user opens a secured 
session from an ICW client to the SPIRITS server. Once a session 
is open, the SPIRITS server will know the relationship between the 
line and the PC (i.e., it will know the Directory Number of the 
user's Internet line and the user's IP Address) . 

3. When a call arrives at a busy Internet line, the SSP will trigger 
the ICW service. The SCP which acts as the SPIRITS client will 
inform the SPIRITS server that a call is terminating to a busy 
internet line. The message will include the Caller ID and Calling 
Line Identify Restriction (CLIR) Status of the calling party, and 
DN of the busy line. 

4. The SPIRITS server will verify that if an ICW session has been 
established for the busy line. If so, the SPIRITS server will 
communicate with the user's ICW client application. The user will 
receive a real-time pop -up dialogue box including the Calling Name 
and Number of the Calling Party if available. The user will then 
select one of the following call management options: 

- Answer the call (the Internet connection will be automatically 
dropped and the phone will ring) 

- Send the call to Voice Mail 

- Forward the call to another destination 
Ignore the call 

5. When the Internet user has made a selection, the ICW client 
application will transmit this to the SPIRITS server. The SPIRITS 
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server will instruct the PSTN via the SCP how to handle the call. 
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5.3. Interfaces and Protocols 

5.3.1. SCP (SPIRITS Client) -SPIRITS Server Interface 

5.3.1.1. Connecting to SPIRITS Services 

The physical connection between the SCP and the SPIRITS server will 
be via a LAN/WAN. The logical connection will use the UDP/IP 
communications as defined in RFC 768 and RFC 1122. 

If a socket connection is not currently established, the SCP will 
periodically try to open a connection. The SCP routing tables will 
be configured so that all available connections to a SPIRITS server 
are used. 

5.3.1.2. Message Types 

Two different types of message are used between the SCP and the 
SPIRITS server: "Connection Management Message Type" and the "Data 
Message Type". These messages will carry the remote operation, 
messages which are based on ITU-T Q.1228 SCF-SCF interface with some 
NEC proprietary extensions, 

NEC also has a plan to support SIP/SDP-based protocols for the SPIR- 
ITS client-server interface in the near future. 

5.3.1.2.1 Connection Management Message Type 

Connection management messages are to support functions related to 
the opening and closing of connections and monitoring connections to 
ensure reliable communications are maintained between the SCP and a 
SPIRITS server. The SCP is responsible for establishing a connection 
to a SPIRITS server. A connection can be closed by either the SCP or 
the SPIRITS server. 

The "Connection Management Message Type" includes the following 
operations : 

- scfBind - scfUnbind - activitytest 
Opening a Connection 

If a connection is not open to an SPIRITS server, the SCP will 
periodically try to open a connection until it is opened. If after a 
pre-determined number of attempts the connection is not opened, the 
socket connection will be released and then re-established and then 
the attempt to open the connection will be repeated. 
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The sequence for opening a connection is: 

1. SCP will transmit a scfBind invokation message to the SPIRITS 
server. This message also carries the version information and 
activity test interval. 

2. The SPIRITS server, upon receiving an invokation of the scfBind 
from a particular SCP, will reset all the data concerning the 
connection and then responds with either a return result containing 
the Web Server Identification number or a return error with a reason. 

3. When the SCP receives a return result, if the ID number does not 
match the number configured in the SCP, then a scf Unbind will be sent 
indicating the wrong ID number. If the SCP receives nothing or a 
return error is received, then the scfBind will be retried after a 
pre-determined period of time. 

4. Once the SCP has received a return result, the SCP will send 
Handling Information Request or Activity Test. 

Upon receiving an invokation of activityTest , the SPIRITS server 
should reply with a return result of activityTest. If the SPIRITS 
server does not receive any invokation messages of Handling 
Information Request or Activity Test from the SCP for four times the 
Activity Test Interval value in milliseconds, the SPIRITS server 
should then close the connection. 

To close a connection an invokation of the scf Unbind is sent by 
either the SCP or SPIRITS server to the remote end. When an 
invokation message of the scfUnbind is received, the receiving end 
should terminate the connection. 



The scfBind operation is used to open the connection between the SCP 
and the SPIRITS server. The SCP will send the SPIRITS server an 
invokation of the scfBind to establish an association. If the 
SPIRITS server is ready to handle the request then it should respond 
with a return result. 

The return result of scfBind contains the identifier of the SPIRITS 
ser>rer. If the SCP receives the return result where the 
identification of the SPIRITS server does not match that registered 
against the SPIRITS server, then the SCP will send an invokation of 
the scfUnbind indicating an incorrect identifier was received. 

If the SPIRITS server is not ready to handle the request or cannot 
handle the version, then it should respond with a return error. 
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The scfUnbind operation is used to close the connection between the 
SCP and the SPIRITS server. Either the SCP or the SPIRITS server can 
invoke this operation. 

Upon receiving an invokation message the receiving end should 
terminate the connection. 

activity-Test 

If the SCP has not sent a Data Message for the time period specified 
by the "Activity Test Interval", it will send an invokation message 
of activityTest . When the SPIRITS server receives such an 
invokation, it will reply with a return result message of 
activityTest . 

Its contents should be retained by the SPIRITS server. They are to 
be echoed back in the return result so that the message reply time 
can be calculated. 

5.3.1.2.2. Data Message Type 

SCPs use the following operations, which are sent to the SPIRITS 
server via a Data-Message-Type message, to request execution of some 
service procedure or notification of an event that takes place at the 
SCPs: 

o handlinginf ormationRequest 

The handlinginf ormationRequest message will request a SPIRITS 
server the execution of some service procedure. 

o handlinginf ormationResult 

The handlinglnformationResult message will show the SCP the result 
of the execution, which was carried out by the SPIRITS server. 

o conf irmedNotif icationProvided 

The conf irmedJSTotif icationProvided message will indicate to the 
SPIRITS server of an event, which takes place at the SCP. If the 
conf irmedNotif icationProvided indicating 'caller abandon' is 
received, the SPIRITS server will inform the client of the caller 
abandon and send the SCP a return result for the 
conf irmedNotif icationProvided. 
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The invoked operation has always a response which is either a 
return result of the operation or an invokation of another 
operation , 

If a Data Message is not replied to within a pre -determined time 
out period then the message will be resent a number of specified 
times. Once the number of times has been exceeded, if another node 
exists, the message will be sent to another node if it is 
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available. If all available SPIRITS servers have been queried then 
Message Time out will be returned to the calling process. 

If an invokation of the handlinginf ormationResult is received with 
the cause=63 (Service not available) , the 

handlinginf ormationRequest will be sent to another node if it is 
available. If all available SPIRITS severs have been queried then 
cause=63 will be returned to the calling process. 

5.3.2. SPIRITS Server-ICW Client Application Interface 

The following is a list of the application messages that are sent via 
the secure protocol (refer to section 5.3.3): 

o Versionlnfo (ICW client -> SPIRITS server) 

Indicate the current version of ICW client software. The SPIRITS 
server uses this information to determine if the client software is 
out of date . 

o VersionlnfoAck (SPIRITS server -> ICW client) 

If the Versionlnfo message from an ICW client indicates to a 
SPIRITS server that it is an out of date version, the URL 
information is returned within the VersionlnfoAck message for use 
in downloading the newer version. If the client software is up to 
date, the message simply indicates so and does not include any URL 
information. 

o CallArrival (SPIRITS server -> ICW client) 

Sent by \the server to tell the client someone has called the DN. 

o CalllD 

An identifier for this call. Unique in the domain of this 
client/server session. 
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o CallingNumber 
o CallingName 

The name of the calling party is sent to the Client Application 
from the SPIRITS server. When available, the name is sent as a 
15 -character string. If the name is unavailable it is sent as 
"Name Unavailable". If the calling party has CLIR set, it is sent 
as empty ( " " ) . 

o CallConnect (ICW client -> SPIRITS server) 

If a corresponding CallConnect is not received within a certain 
period after sending a CallArrival, the SPIRITS server will behave 
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as though a CallConnect, Handling=Ignore had been received. 

o CallLost (SPIRITS server -> ICW client) \ 

Sent by server to cancel a CallArrival before a CallConnect is 
received by the server. 

5.3.3. Secure Reliable Hybrid Datagram Session Protocol (SRHDSP) for Use 
Between ICW Client Application and SPIRITS Server 

5.3.3.1. Overview 

In principle the solution involves session initiation over SSL 
(meeting requirements for standards based security) after which the 
SSL session is closed, thereby reducing the number of simultaneous 
TCP/IP sessions. The rest of the session is communicated over 
UDP/IP, secured using keys and other parameters exchanged securely 
during the SSL session. 

5.3.3.2. Session Initiation 

The ICW client initiates an SRHDSP session, by reserving a UDP/IP 
port, and opening an SSL session with the service (e.g., ICW) on the 
service's well known SSL/TCP port.. After establishing the SSL 
Session, the ICW client sends the server its IP address, the reserved 
UDP port number, and the set of supported symmetric key algorithms. 

The server responds with a symmetric key algorithm chosen from the 
set, the server's UDP port for further communication, heartbeat' 
period, and the value to use for the sequencing window. 
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The cilient then generates a symmetric key using the selected 
algorithm and transmits this to the server. The SSL session is then 
closed and the SRHDSP session is considered open. 

5.5.3.3. Secure Reliable Datagram Transport 

Application, and subsequent session management messages use symmetric 
signaling. That is, the signaling is the same whether the client is 
sending a message or the server is sending a message. 

The. message packets are transmitted securely. The protocol corrects 
for lost., duplicated and out of sequence packets. 

5.3.3.4. Session closure 

The client or server may close the session. 

A session is closed using a Close message including the next sequence 
number, and encrypted with the agreed key. 
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The receiver, on processing (as opposed to receiving) a Close 
message, should set a timer, when the timer expires all details of 
the session should be forgotten. The timer is to allow for 
retransmission of the close if the Ack gets lost, we still need to be 
able to decrypt the subsequent retransmission and re - acknowledgment . 

If any message other than a close is received after a close is 
processed, it is ignored. 

6. Telia/Nortel's Implementation 

6.1. Overview 

The system implemented by Telia in cooperation with Nortel Networks 

is designed to support seirvices that execute before the end-to-end 

media sessions are established. These services include, for example: 

- call transfer and number portability for redirecting calls 

- call waiting and call offering for announcing a pending call 

- call screening and don't disturb for filtering incoming calls 

- automatic call distribution and 800-services for selecting 
termination point 

The Telia/Nortel system aims to allow service providers to develop 
the services mentioned above. Presently, prototypes for online 
incoming call disposition and automatic incoming call disposition 
(described in Section 2) have been developed to prove the concept. 
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In the Telia/Nortel architecture, services run on top of SIP Redirect 
Servers. The distributed nature of SIP enables these servers to be 
hosted, for example, by an enterprise server, a Service Provider's 
server cluster, a user's desktop PC, or even by a hand-held cordless 
device . 

The SIP Redirect Server receives a SIP INVITE message for each call 
regardless of which network the call is being set up in. The server 
MAY apply any kind of service logic in order to decide on how to 
respond to the invitation. Ser\''ice Togic may interact with the user 
to allow the user to specify how to handle a call such as described 
in Section 2. This, however, is not the focus of the Telia/Nortel 
system. 

6.2. Architecture and Protocols 

The general idea behind the architecture is to create services as if 
all communication was based on IP and all clients and servers were 
SIP enabled. This of cause is not true in existing 
telecommunications networks. Hence, a new type of network element, 
the Service Control Gateways (SCG) hides the true situation from the 
services . 

SCGs convert network-specific call control signaling to SIP messages 
and vice versa. A SCG behaves as a regular SIP User Agent (UA) 
towards the services and as a network- specif ic service control node 
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in the network where the call is being set up. For example, when 
connecting to a GSM network, the SCG can play the role of an SCP or a 
MAP or an ISUP proxy. The specific role depends on what service 
triggers are being used in the GSM network. 

SCGs handle protocol conversions but not address translation, such as 
telephone number to SIP URL, which is handled by a regular SIP Server 
to keep the SCG as simple as possible. 

Consider a service example of number portability. A conventional 
number portability implementation in a mobile Circuit Switched 
Network (CSN) uses INAP messages to carry number queries to a 
network- internal data base application. Here, a SCG and a high- 
performance SIP Redirect Server, referred to as the Number Server 
(NS) , have replaced the data base typically located in an SCP. (See 
Figure 11.) 
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+ + IN;^P + + SIP + + 

I CSN node | | SCG | | NS (SIP Redirect Server) | 

+ + + + + + 

Figure 11: An Architecture for Number Portability 

The INAP IDP message that carries the number query is converted to a 
SIP INVITE message by the SCG and is then forwarded to the NS (SIP 
Redirect Server) . 

If the called number is not registered, then the NS will return "404 
Not Found". The SCG interprets this as "non ported number" and 
returns a CON message to the CSN network, making it connect the call 
to the called number. 

If the number is ported and hence registered, then the NS will return 
"3 01 Moved Permanently" with a TEL URL (routing number) in the 
contact field. The SCG then returns a CON message to the CSN 
network, making it connect the call to the number that was conveyed 
in the contact field. 

The solution above enables the same Number Server to provide Number 
Portability to multiple networks by means of using multiple SCGs. 

If we make the SIP server in the number portability example operate 
in proxy mode for selected numbers, then it will become a kind of 
service router, able to relay number queries to any SIP-Redirect- 
Server "based service anywhere, provided there is an IP connection to 
the host in concern. Figure 12 shows the arrangement. 

+ INAP + + SIP + + SIP + + 

I CSN I 1 SCG I I NS I I Service | 
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I node I III (redirect/proxy) | | (redirect) | 
^ + + + + + + + 

Figure 12 : SIP-Based Service Router 

Suppose that we connect a value-added service, such as a Personal 
Call Filtering service hosted by a user's desktop PC, to a certain 
telephone number. The INAP IDP message is converted to a SIP INVITE 
message by the SCO and is then forwarded to the NS, just as in the 
previous example. However, in this case, the number is registered 
with a reference to a SIP URL. This makes the Number Server proxy 
the SIP INVITE message to the registered URL, which is the address of 
the service. 
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The service responds as a SIP Redirect Server and the Personal Call 
Filtering service logic determines the response. The NS sends the 
response back to the SCG which converts the response to an 
appropriate INAP message. The response from the service is typically 
"302 Moved Temporarily" with a telephone number in the Contact field. 

If the response is 301 or 302, as the examples above suggest, then a 
telephone number is carried in the contact field. If the user can be 
reached via .several different addresses, then all of them SHOULD be 
added to the response by means of multiple contact fields. The SCG 
then selects an address that is valid for the node or application 
that issued the number query. 

As illustrated by the service examples, the Telia/Nortel system aims 
to allow the introduction of multi -network services without requiring 
multi -protocol support. The services hence operate in the same way 
regardless of in which network the call is made and common IP 
services can be shared across heterogeneous networks. 
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Figure 13 : Interconnecting Heterogeneous Networks via SIP 
6,3. Security 



ftp://ftp.rfc-editor.org/in-notes/rfc2995.txt 



5/31/05 



Page 36 of 40 



The Telia/Nortel architecture uses security mechanisms available to 
ordinary SIP services, implemented as they would be in a pure SIP 
network. The architecture described here does not impose any 
additional security considerations. 

General security issues that must be considered include 
interconnection of two different networks. SCGs must therefore 
include mechanisms that prevent destructive service control signaling 
from one network to the other. For example, a firewall -type 
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mechanism that can block a denial -of- service attack from an Internet 
user toward the PSTN. 

7 . Security Considerations 

Overall, the SPIRITS security requirements are essentially the same 
as those for PINT [3, 4], which include, for example: 

+ Protection of the PSTN from attacks from the Internet. 

+ Peer entity authentication to allow a communicating entity to 
prove its identity to another in the network. 

+ Authorization and access control to verify if a network entity 
is allowed to use a network resource. 

+ Confidentiality to avoid disclosure of information (e.g., the 
end user profile information and data) without the permission of 
its owner. 

+ Non-repudiation to account for all operations in case of doubt 
or dispute . 

As seen in the previous sections, most implementations examined in 
this document have employed means (e.g., firewalls and encryption) to 
meet these requirements. The means are, however, different from 
implementation to implementation. 

3 . Conclusion 

This document has provided information relevant to the development of 
inter-networking interfaces between the PSTN and Internet for 
supporting SPIRITS services. Specifically, it described four 
existing implementations of SPIRITS-like services. Surveying these 
implementations, we can make the following observations: 

o The ICW service plays the role of a benchmark service. All four 
implementations can support ICW, with three specifically designed 
for it. 

o SIP is used in most of the implementations as the based 

communications protocol between the PSTN and Internet. (NEC*s 
implementation is the only exception that uses a proprietary 
protocol. Nevertheless, NEC has a plan to support SIP together 
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o All implementations use IN-based solutions for the PSTN part. 
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It is clear that not all pre-SPIRITS implementations inter-operate 
with each other. It is also clear that not all SIP-based 
implementations inter-operate with each other given that they do not 
support the same version of SIP. It is a task of the SPIRITS Working 
Group to define the inter-networking interfaces that will support 
inter-operation of the future implementations of SPIRITS services. 
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kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
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developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
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Lucent , based in Murray Hill, N.J., last week made two introductions: a 
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service node /intelligent peripheral, that allows service providers to 
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...other services, said Jennifer Byers, Lucent's IN product management 
director , 
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a service control point in a network-and the suite of applications enable 
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Rhode Island and Vermont. 

PR Newswire, pNYTU16523042002 
April 23, 2002 

Language: English Record Type: Fulltext 
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69 and Call Trace. 
Talking Call Waiting and Verizon's basic Call Waiting services use 
Lucent Technologies' Compact Service Node hardware and software. 
With the new service, the name of the caller is retrieved from a Verizon 
database by the network switch and sent in text format to the Lucent 
service node for text-to-speech conversion. After the Call Waiting tone, 
the Talking Call. . . 
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Who's on the Line When Call Waiting Beeps? Now, Verizon's Talking Call 
Waiting Will Tell You; New Service Available in Western Massachusetts. 

PR Newswire, pNA 
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Language: English Record Type: Fulltext 
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69 and Call Trace. 
Talking Call Waiting and Verizon's basic Call Waiting services' use 
Lucent Technologies' Compact Service Node hardware and software. 
With the new service, the name of the caller is retrieved from a Verizon 
database by the network switch and sent in text format to the Lucent 
service node for text-to-speech conversion. The innovative Lucent 
technology then speaks the name to the Talking Call Waiting subscriber 
after the Call Waiting. . . 
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Talking Call Waiting Debuts in Massachusetts . 

PR Newswire, pNA 
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... Call Trace. Talking Call Waiting operates along with Verizon's 

regular Call Waiting Service using Lucent Technologies' Compact 
Service Node hardware and software. With the new service, the name is 



retrieved from a Verizon database by the network switch and sent in text 
format to the Lucent service node for text-to-speech conversion. The 
innovative Lucent technology then speaks the name to the called 
subscribers only, along with the initial Call... 
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(USE FORMAT 7 FOR FULLTEXT) 
TEXT: 

Lucen t Technologies (Murray Hill, NJ — 800-4LUCENT, www. lucent 
.com/software) has unveiled the first bundle in a series of calling 
services that CLECs can use to keep and gain more revenue from customers . 
Programmed to run on the Lucent Compact Service Node 
(CSN) /intelligent peripheral, these will be offered for the networks of 
emerging carriers, either bundled. . . 
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... and other unwanted calls. 

Privacy Manager will be the first service Ameritech will offer 
through Lucent ' s new intelligent network platform , called Compact 
Service Node /Intelligent Peripheral (CSN/IP) . The platform enables 
Ameritech and other service providers to create and offer a variety of new 
services . . . 

...between the two companies makes Ameritech the first customer for the new 
platform designed by Lucent 's Bell Labs. 

"Lucent's hardware and software enables Ameritech to quickly and 
efficiently offer... 

...IP platform-installed in the service provider's central offices and 
administrative centers-consists of: 

Compact Service Node (CSN) o recognizes and responds to 
customer requests for services. Lucent 's CSN supports nearly all brands 
of wireline and wireless call-routing switches in service... 
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... and other unwanted calls. 

Privacy Manager will be the first service Ameritech will offer 
through Lucent 's new intelligent network platform , called Compact 
Service Node /Intelligent Peripheral (CSN/IP) . The platform enables 
Ameritech and other service providers to create and offer a variety of new 
services . . . 

...between the two companies makes Ameritech the first customer for the new 
platform designed by Lucent 's Bell Labs. 

"Lucent ' s hardware and software enables Ameritech to quickly and 
efficiently offer... 
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Deals This Week 
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Word Count: 1011 

Hoffman, 650/857-1501; Biscom, Scott Bonnell, 978/250-1800 
Lucent Technologies (NEV) Ameritech (CLEG) 
Lucent Technologies [LU] is providing Ameritech Corp. [AIT] with 
software and hardware support to the company's Privacy Manager with Sales 
Screener personal call manager under a three-year contract. Lucent 's 
support for the network is the Compact Service node /Intelligent 
Peripheral, which supports a combination of integrated voice, data and 
messaging and multimedia. 
* Announced. . . 



8/3,K/10 (Item 8 from file: 16) 

DIALOG (R) File 16: Gale Group PROMT (R) 

(c) 2005 The Gale Group. All rts. reserv. 

05548750 Supplier Number: 48409770 (USE FORMAT 7 FOR FULLTEXT) 
Excel Adds Aethos to Partner Program. 

Business Wire, p04071256 
April 7, 1998 

Language: English Record Type: Fulltext 
Document Type: Newswire; Trade 



Word Count: 44 3 



... ONE Architecture by incorporating Excel *s open, programmable 

switches into the foundation of the Aethos Intelligent Network Service 

Node . The service node is a platform designed to facilitate the rapid 
development and deployment of advanced services, with the shortest possible 
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CELLULAR WIN: HP OPENCALL SELECTED AS ARCHITECTURE FOR MOTOROLA 

INTELLIGENT - NETWORK SERVICE NODE ; HP OPENCALL COMPONENTS AND 
SERVERS TO BE USED BY MOTOROLA CELLULAR INFRASTRUCTURE GROUP 
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... the many benefits of AccessLine's unique technology." 

AccessLine's One Person, One Number service platform is an advanced 
intelligent network service node that is the most widely deployed 
system of its kind in the world today. Operating. . . 
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... the many benefits of AccessLine's unique technology." 

AccessLine's One Person, One Number service platform is an advanced 
intelligent network service node that is the most widely deployed 
system of its kind in the world today. Operating... 
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have personal freedom, flexibility, and accessibility on their 

terms . 

THE TECHNOLOGY The One Number Service platform is an advanced 
intelligent network service node that is the most widely deployed 
system of its kind in the world today. Operating... 
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Call Trace. 

Talking Call Waiting and Verizon's basic Call Waiting services use 
Lucent Technologies' Compact Service Node hardware and software. With 
the new service, the name of the caller is retrieved from a Verizon 
database by the network switch and sent in text format to the Lucent 
service node for text-to-speech conversion. After the Call Waiting tone, 
the Talking Call . . . 
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LUCENT TECHNOLOGIES: Cavalier Telephone buys Lucent Internet Call Waiting 
software 
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forwarding telephone calls received while connected to the 

Internet . 

The software, loaded on Lucent's Compact Service Node and 

deployed in a service provider's network, recognizes and responds to 
customer requests for services. Lucent 's Compact SN supports nearly all 
brands of call-routing switches in service providers' networks... 
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... migrate to the complete Personal Assistant service over time. 

Deployed on Lucent's standards-based Intelligent Network Service 
Node or Compact Service Node , Personal Assistant will operate on a 
variety of fixed and mobile communications networks throughout the world. 

Lucent 's proven Intelligent Network platforms provide the reliability and 
scalebility needed to deploy revenue generating. . . 

... Assistant to expanding markets. Personal Assistant also leverages 
international language expertise from Bell Labs and Lucent Speech 
Solutions, allowing Lucent to offer future versions of the service 
optimized for common languages in North America, South. . . 
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... migrate to the complete Personal Assistant service over time. 

Deployed on Lucent's standards-based Intelligent Network Service 
Node or Compact Service Node , Personal Assistant will operate on a 
variety of fixed and mobile communications networks throughout the world. 

Lucent 's proven Intelligent Network platforms provide the reliability and 
scalebility needed to deploy revenue generating. . . 

... Assistant to expanding markets. Personal Assistant also leverages 
international language expertise from Bell Labs and Lucent Speech 



Solutions, allowing Lucent to offer future versions of the service 
optimized for common languages in North America, South. . . 
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Manager will be the first service Ameritech will offer through 
Lucent's new intelligent network platform , called Compact Service 

Node /Intelligent Peripheral (CSN/IP) . The platform enables Ameritech 
and other service providers to create and offer a variety of new services 

. . .between the two companies makes Ameritech the first customer for the new 
platform designed by Lucent 's Bell Labs. 

"Lucent's hardware and software enables Ameritech to quickly and 
efficiently offer... 
...centers-consists of: 

* Compact Service Node (CSN) - recognizes and responds to customer 
requests for services. Lucent 's CSN supports nearly all brands of 
wireline and wireless call-routing switches in service... 
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. . . service providers to roll out new revenue-generating services 
quickly and economically. 

Lucent's new Compact Service Node /Intelligent Peripheral (SN/IP) 
solutions provide the capability for service providers to offer their 
customers ... 
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Nippon Telegraph and Telephone Corp. (NTT) and AccessLine Technologies to 
deliver One Person, One N\ainber(R) service in Japan. 
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have personal freedom, flexibility, and accessibility on their 

terms. 

The Technology 

The One Number Service platform is an advanced intelligent 
network service node that is the most widely deployed system of its 
kind in the world today. Operating. . . 
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NEW PRIVACY MANAGER SERVICE USES LUCENT'S INTELLIGENT NETWORK 
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LANGUAGE: ENGLISH WORD COUNT: 399 RECORD TYPE: FULLTEXT 
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TEXT: 

...to block telemarketing and other unwanted calls. 
Ameritech has incorporated Murray Hill, N.J. -based Lucent 
Technologies ' s [LU] Compact Service Node /Intelligent Peripheral 
(SN/IP) hardware and software in its new Privacy Manager with Sales 
Screener . . . 

... IN Line 

Ameritech is the first customer for the new intelligent network 
platform designed by Lucent 's Bell Labs. Lucent introduced the CSN/IP 
platform in March and Ameritech tested it for three months. The... 
... in 

Chicago and Detroit for $3.95 a month. 

Jack Kozik, architecture planning director for Lucent 's IN area, 
says the intelligent network platform solutions are customer-friendly, 
making services quick. . . 

...is just another way for carriers to better 
serve their customers," he says. 

"Because the Compact Service Node has a standard interface, it 

was able to plug into the customers' network. The Privacy Manager 

Service, in the case of the Compact Service Node , is sized right for 

the needs of the service," Kozik continues. 

The CSN/IP offers. . . 

. . . updating 

announcements for their individual needs, eliminating the need for 
expensive manual procedures . 

(Gordon Zwirkoski, Lucent , 84 7-290-3382; Dave Onak, Ameritech, 
312/750-5639.) 
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Business Wire Recap 

March 25, 1996 

Byline: EDITORS 

...expanded USPS Order (BW1247 11:16) 

(HEWLETT-PACKARD-4 ) (HWP) DALLAS — HP OpenCall Selected as 
Architecture for Motorola Intelligent - Network Service Node ; 

(BW0134 11:17) 

(HITACHI /TEACHER- EXCHANGE) (HIT) TARRYTOWN, N.Y. — Japanese 
teachers visit Westchester schools.,. 
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HEWLETT PACBCARD 4: HP OpenCall Selected as Architecture for Motorola 
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March 25, 1996 

Byline: Business Editors/Computer Writers 

HP OpenCall Selected as Architecture for Motorola Intelligent - Network 
Service Node ; HP OpenCall Components and Servers to be Used by 

Motorola Cellular Infrastructure Group 
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Lucent Launches Low-cost IN 
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WORD COUNT: 331 

TEXT: 

By Brad Smith 

Lucent Technologies Inc. last week unveiled a scalable intelligent network 
platform with a suite of software applications that will allow a broad 
range of wireless carriers to offer customized services to their 
subscribers at a low cost. 

"Carriers will be able to get into new IN-based services without investing 
millions of dollars, " said Mona Johnson, executive director of the IN Forum 
and owner of the consulting firm Technical Marketing Inc. of St. 
Petersburg, Fla. She predicted Lucent's new platform and applications would 
be particularly attractive to smaller carriers that want enhanced services. 

figure omitted 

Lucent , based in Murray Hill, N.J., last week made two- introductions: a " 
scalable computer-telephony integration platform , called a compact 
service node /intelligent peripheral, that allows service providers to 
offer the new applications; and a suite of new applications for carriers 
using either global system for mobile communications or Interim Standard-41 
that offers "anytime, anywhere" roaming. 

The wireless applications include advanced features such as prepaid use, 
virtual private networks, voice-activated dialing, flexible alerting, local 
number portability, enhanced 911, personal number, usage limitation and 
advanced routing services. 

The personal number and usage limitation features are available only to GSM 
carriers through subscriber identity module cards, while local number 
portability and E911 are being offered only for IS-41 systems. 

Lucent expects the application suite will be one answer for the huge costs 
wireless carriers face in the next few years to provide local number 
portability. Portability may not be a revenue-generator, but carriers might 
recoup some of the cost by being able to provide subscribers the other 
services, said Jennifer Byers, Lucent's IN product management director. 

The combination of the compact service node platform -deployed with 
a service control point in a network-and the suite of applications enable 
carriers to "pay-as-you-go" with minimal hardware costs and the ability to 
migrate to larger operations, Byers said. 

The compact SN/IP platform allows the combination and integration of voice, 
data, messaging and multimedia across a network, Lucent's announcement 
said. Because the platform supports Internet protocols, it bridges voice 
and data networks. 

Copyright 1998 Reed Business Information 
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Who's on the Line When Call Waiting Beeps? 

PR NEWSWIRE 
April 23, 2002 

Consumers in Maine, New Hampshire, Rhode Island and Vermont no longer 
need to wonder who's calling when they hear the Call Waiting beep on their 
phone line. With Verizon's new Talking Call Waiting service, they'll also 
hear the name of the caller, 

"Talking Call Waiting is another tool our customers can use to manage 
their calls, their time and their lives," said Anne Kraus-Keenan, Verizon's 
group manager of new product development. "Like Caller ID, Talking Call 
Waiting takes the mystery out of who's calling." 

The service is already available to Verizon customers in the New York 
City area, Massachusetts and New Jersey. Verizon plans to offer the service 
to several additional markets in the coming months. 

' "With' Talking Call Waiting, customers can decide who they'll talk to 
and when, ' letting them decide between business calls and social calls, 
urgent calls or leisure calls, customer calls or supplier calls," 
Kraus-Keenan said. 

The monthly charge for Talking Call Waiting varies by state, ranging 
from $5.75 to $7.50. The cost includes basic Call Waiting service. 
Customers can get the service for as low as $2 a month when purchased with 
several service packages. The service does not require any additional 
equipment . 

Verizon's advanced network provides Talking Call Waiting by using 
information about the originating number that is needed to set up calls. 
That information also is used by the network to enable other features like 
Caller ID, *69 and Call Trace. 

Talking Call Waiting and Verizon's basic Call Waiting services use 
Lucent Technologies' Compact Service Node hardware and software. With 
the new service, the name of the caller is retrieved from a Verizon 
database by the network switch and sent in text format to the Lucent 
service node for text-to-speech conversion. After the Call Waiting tone, 
the Talking Call Waiting subscriber hears the name of the caller. 
Subscribers can decide whether to interrupt their current call to take the 
incoming call. 

According to Kraus-Keenan, the new service also will be valuable to 
customers who are visually impaired or physically disabled. These consumers 
are not able to use Caller ID because they cannot see or get to the display 
box to read the incoming caller's number. 

To sample the Talking Call Waiting message, visit Verizon's online 
News Center, http://www.verizon.com/news, open this news release and click 
on the sample sound files. 

Verizon Communications is one of the world's leading providers of 
communications services. Verizon companies are the largest providers of 
wireline and wireless communications in the United States, with 133.8 
million access line equivalents and approximately 29.6 million wireless 
customers. Verizon is also the largest directory publisher in the world. 
With more than $67 billion in annual revenues and nearly 248,000 employees, 
Verizon's global presence extends to more than 40 countries in the 
Americas, Europe, Asia and the Pacific. For more information on Verizon, 
visit http://www.verizon.com . 

VERIZON'S ONLINE NEWS CENTER: Verizon news releases, executive 
speeches and biographies, media contacts and other information are 
available at Verizon's News Center on the World Wide Web at 
http://www.verizon.com/news. To receive news releases by e-mail, visit the 



News Center and register for customized automatic delivery of Verizon news 
releases . 

MAKE YOUR OPINION COUNT - Click Here http://tbutton.prnewswire.com/prn 
/11690X63871103 Verizon Communications 

Contact: Lacy Yeatts, +1-804-779-4097, lacy.yeatts@verizon.com, Peter 
Reilly, Maine, +1-207-797-1335, peter.j.reilly@verizon.com. Bob Noble, New 
Hampshire, +1-617-743-3433, robert . c . noble@verizon . com, Tracey Kennedy, 
Rhode Island, +1-401-525-3631, tracey.a.kennedy@verizon.com, or Beth 
Fastiggi, Vermont, +1-802-863-0797, m.b.fastiggi@verizon.com, all of 
Verizon 

Website: http://www.verizon.com/ 

Company News On-Call: http://www.prnewswire.com/comp/094251.html 

Copyright 2002 PR Newswire. Source: Financial Times Information 
Limited. 
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LUCENT TECHNOLOGIES: Lucent introduces personal asst technology for broad 
consumer and business markets 

m PRESSWIRE 
January 28, 1999 

WASHINGTON, D.C. — Lucent Technologies today introduced the first 
mass market personal productivity software tool which uses spoken commands 
to control and screen incoming phone calls, simplify outbound calls and 
manage voice mail. The Lucent Personal Assistant delivers easier to use, 
lower-cost virtual assistant technology than was previously available, and 
is designed for both consumer and business markets. Personal Assistant is 
available for telephone and mobile service providers, who install the 
software in their networks and then offer service subscriptions to their 
customers. The announcement was made here today at ComNet '99, an annual 
exhibition for the networking and telecommunications industries. 

Personal Assistant combines Lucent's cost-effective Intelligent 
Network platform and unique Bell Labs speech processing technology to 
create a simplified, lower-cost service than previous personal/virtual 
assistant offerings. Unlike complex assistant services that bill by the 
minute and appeal only to limited niche markets, Lucent's intuitive 
Personal Assistant is designed to be offered for a low monthly subscription 
to the sizable home and business telephone markets, as well as the growing 
legion of mobile users. 

Lucent created a user-friendly personal assistant service by avoiding 
needless complexity, concentrating instead on the basic functions of an 
assistant: 

Screen calls-Personal Assistant answers incoming calls, identifies who 
is calling, then lets users respond by voice to answer a given call or to 
instruct the assistant to send the call to voice mail. Place calls-Personal 
Assistant allows subscribers to dial calls by simply speaking a name or 
phone number. 

Take messages-Personal Assistant streamlines voice mail playback by 
grouping messages by caller's names (e.g., "You have two messages from John 
Smith and one message from Mary Jones"), then allowing the subscriber to 
quickly select by voice which messages he or she wants to hear (e.g., "Play 
the message from Mary Jones") . 

Find the subscriber as needed- Personal Assistant uses call forwarding 
or sequential ringing (ringing phones in different locations in a 
particular order) to locate subscribers and notify them of an incoming 
call, even if they are already on a different call. 

"Personal Assistant leverages critical technologies developed across 
several Lucent businesses, including Intelligent Networking software, 
speech recognition from Bell Labs and voice messaging from the Octel unit, " 
said Lance Boxer, group president, communications software, Lucent 
Technologies. "The combined technologies are specifically designed with 
broad home and office usability and af f ordability, which is also attractive 
for communications providers seeking new, revenue-enhancing service 
offerings for their subscribers." 

Personal Assistant also addresses the call management needs of 
business users, who struggle to keep up with the crush of calls and voice 
mail. Additionally, Personal Assistant's simplicity is intended to appeal 
to the average home user, who has become more protective of personal 
privacy and is seeking to control interruptions to personal time. Personal 
Assistant is also a vast improvement for mobile users, who often find 
themselves working from their cars, where constantly entering keypad 
commands can be difficult. Personal Assistant's spoken, hands-free 



interface is a more-efficient method for mobile communications. 

To further promote the mass market acceptance of the virtual assistant 
concept, Lucent will make selected features of Personal Assistant, such as 
Voice Dialing and Call Screening, available as stand-alone. Intelligent 
Network-based services. This building block approach allows service 
providers to offer targeted services that reflect the specific needs of a 
variety of markets. The end result is a unique suite of assistant services 
that build on users' existing experience, allowing subscribers to easily 
migrate to the complete Personal Assistant service over time. 

Deployed on Lucent's standards-based Intelligent Network Service 
Node or Compact Service Node , Personal Assistant will operate on a 
variety of fixed and mobile communications networks throughout the world. 

Lucent 's proven Intelligent Network platforms provide the reliability and 
scalebility needed to deploy revenue generating services such as Personal 
Assistant to expanding markets. Personal Assistant also leverages 
international language expertise from Bell Labs and Lucent Speech 
Solutions, allowing Lucent ' to offer future versions of the service 
optimized for common languages in North America, South America and Europe. 

A market trial version of Personal Assistant is currently available on 
a limited basis to North American service providers. 

ABOUT LUCENT TECHNOLOGIES Lucent Technologies, headquartered in Murray 
Hill, N.J., designs, builds and delivers a wide range of public and private 
networks, communications systems and software, data networking systems, 
business telephone systems and microelectronic components. Bell Labs is the 
research and development arm for the company. More information about Lucent 
Technologies is available on the company's Web site at: 
http : / /www . lucent . com . 

CONTACT: Rich Teplitsky, Lucent Technologies Tel: +1 908 582 5700 
e-mail: rteplitsky@lucent.com Dan Coulter, Lucent Technologies Tel: +1 908 
580 4111 e-mail: dlcoulter@lucent.com 

*M2 COMMUNICATIONS DISCLAIMS ALL LIABILITY FOR INFORMATION PROVIDED 
WITHIN M2 PRESSWIRE. DATA SUPPLIED BY NAMED PARTY/ PARTIES . * 

Copyright 1999 M2 Communications Ltd.. Source: World Reporter (Trade 
Mark) . 
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LUCENT TECHNOLOGIES: Intelligent network software solutions enable rapid 
deployment of new services 

M2 PRESSWIRE 
March 31, 1998 

Lucent Technologies today introduced intelligent network software 
solutions, including a scalable computer-telephony integration (CTI) 
platform, that enables network service providers to roll out new 
revenue-generating services quickly and economically. 

Lucent's new Compact Service Node /Intelligent Peripheral (SN/IP) 
solutions provide the capability for service providers to offer their 
customers advanced features such as interactive voice response, customized 
announcements, voice-activated dialing and advanced Internet services such 
as Internet call waiting, as well as the ability to brand services with 
customized announcements. Business customers can access and update a set of 
announcements tailored to their individual needs, automatically and without 
using expensive manual procedures. 

"Designed by Bell Labs, these solutions offer network service 
providers a cost effective way to invent and develop distinctive, 
high-demand new service offerings, and bring them to market more quickly 
than they could in the past, " said Curtis Holmes, intelligent-network vice 
president for Lucent's Communications Software Group. "This is the right 
solution to help providers stay ahead of issues such as technological 
change, deregulation and the increasing mobility of customers. It's IN with 
a real competitive edge. " 

The Compact SN/IP is a multiple application platform on which the full 
spectrum of voice, data, messaging and multimedia can be readily combined 
and integrated across a network. This gives service providers the ability 
to react quickly to grow revenue streams in specific services while 
maintaining a consistent approach to providing advanced, interactive 
services , 

The Compact SN/IP combines the reliability of the telephone network 
with the flexibility of the Internet. Because the Compact SN/IP supports 
Internet protocols, it is well positioned as a bridge between voice and 
data networks. Information from the Internet can be retrieved and delivered 
to anyone on the telephone. Conversely, voice calls and data from the 
switched telephone network can be delivered to emerging data networks. 

Intelligent Peripheral software is a key component in deploying 
efficient, integrated service solutions which are quickly replacing the 
non-integrated "point solutions" of the past. Integrated solutions can 
eliminate long set-up times, which could cause service providers problems. 

Lucent Technologies, headquartered in Murray Hill, N.J., designs, 
builds and delivers a wide range of public and private networks, 
communications systems and software, data networking systems, business 
telephone systems and microelectronic components: 

Bell Labs is the research and development arm for the company. For 
more information on Lucent Technologies, visit the company's web site at 
http : / /www . lucent , com . 

CONTACT: Dan Coulter, Lucent Technologies Tel: +1 908 580 4111 e-mail: 
dlcoulter@lucent.com Donna Cunningham, Lucent Technologies Tel: +1 802 482 
3748 e-mail: donnac@lucent.com 

Copyright 1998 M2 Communications Ltd. . Source: World Reporter (Trade 
Mark) . 
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NEW PRIVACY MAKAGER SERVICE USES LUCENT'S INTELLIGENT NETWORK 

INTELLIGENT NETWORK NEWS 
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TEXT: 

Chicago-based Ameritech [AIT] has introduced a new privacy 

service which will offer residential customers the choice and control 

to block telemarketing and other unwanted calls. 

Ameritech has incorporated Murray Hill, N.J. -based Lucent 

Technologies ' s [LU] Compact Service Node /Intelligent Peripheral 

(SN/IP) hardware and software in its new Privacy Manager with Sales 

Screener Service. 

Privacy Manager intercepts all incoming calls that register as 
"private, " "blocked, " "out of area, " "unavailable, " or "unknown" on 
Caller ID displays. 

The caller is then asked to record his/her name before the call 
is connected. The subscriber is told who is calling and then has the 
choice of accepting the call, rejecting the call or playing a recorded 
message stating the subscriber does not accept telemarketing calls. 
The caller is disconnected if he/she does not offer their name. 
Ameritech found in testing Privacy Manager that approximately seven 
out of every ten unidentified callers hung up when intercepted by the 
service . 

First IN Line 

Ameritech is the first customer for the new intelligent network 
platform designed by Lucent 's Bell Labs. Lucent introduced the CSN/IP 
platform in March and Ameritech tested it for three months. The 
companies agreed to a three-year multimillion dollar contract, but 
neither would not reveal the actual amount. Ameritech 's service works 
in conjunction with Caller ID with Name and is being introduced in 
Chicago and Detroit for $3.95 a month. 

Jack Kozik, architecture planning director for Lucent 's IN area, 
says the intelligent network platform solutions are customer-friendly, 
making services quick and economical. 

"Our customers are keeping an eye towards Internet Protocol as a 
source of revenue and an improved way of providing services for their 
customers. The Internet is just another way for carriers to better 
serve their customers," he says. 

"Because the Compact Service Node has a standard interface, it 
was able to plug into the customers' network. The Privacy Manager 
Service, in the case of the Compact Service Node , is sized right for 
the needs of the service," Kozik continues. 

The CSN/IP offers advanced voice, data, messaging and multimedia 
features so service providers can integrate wireless, wireline or 
Internet service provider networks and deliver services such as speech 
recognition, text-to-speech, fax services and recorded announcements. 
The customer has the capability of accessing and updating 
announcements for their individual needs, eliminating the need for 
expensive manual procedures. 

(Gordon Zwirkoski, Lucent , 847-290-3382; Dave Onak, Ameritech, 



312/750-5639.) 
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